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PREFACE 


This  report  was  prepared  as  a  supplement  to  the  Engineering  Data 
Compendium  being  developed  under  the  Integrated  Perceptual  Information  for 
Designers  (IPID)  project.  IPID  is  concerned  with  the  consolidation  and 
technical  presentation  of  perceptual  and  human  performance  data  to  enable 
their  use  as  an  effective  resource  by  designers  of  simulators  and  opera¬ 
tional  displays  and  controls.  It  is  a  multi-agency  effort  supported  by  the 
Air  Force,  Army,  Navy  and  NASA  and  is  managed  by  the  Air  Force  Aerospace 
Medical  Research  Laboratory  at  Wright-Patterson  AFB. 

The  pertinent  research  literature  contains  a  staggering  volume  of 
potentially  valuable  human  performance  data  and  principles  that  have  not 
been  systematically  considered  for  systems  design.  Early  in  the  IPID 
project,  the  domains  of  sensation,  perception,  human  information  processing 
and  performance  were  reviewed  with  respect  to  their  potential  value  to 
control  and  information  display  design.  Forty-five  technical  subareas  were 
then  selected  for  detailed  treatment  in  a  Handbook  of  Perception  and  Human 
Performance.  These  subareas  were  authored  by  some  65  recognized  subject- 
matter  experts.  The  handbook  is  to  be  published  in  early  1986  by  John 
Wiley  and  Sons  as  a  two-volume  work  of  approximately  3000  pages.  The 
information  in  the  Handbook  was  organized  so  that  it  would  be  amenable  to 
distillation  into  specialized  data  abstracts  or  entries  for  consolidation 
into  an  Engineering  Data  Compendium.  The  emphasis  of  the  Compendium  is  on 
a  usable  presentation  of  behavioral  data  to  design  engineers. 

In  addition  to  the  basic  research  topics  covered  by  the  Handbook,  the 
following  areas  of  investigation  were  reviewed  by  subject-matter  experts  to 
identify  useful  data  for  extending  the  range  of  the  Compendium  to  the 
applied  research  domains: 

-  Information  coding,  portrayal  and  format 

-  Target  detection,  recognition  and  identification 

-  Automation  and  allocation  of  functions 

-  Person-computer  dialogue 

-  Feedback,  warning  and  attentional  directors 

-  Human  performance  reliability 

-  Controls 

-  Vibration  and  visual  displays 

This  report  on  Person-Computer  Dialogue  has  been  produced  as  a  separ¬ 
ate  volume  from  the  Compendium  to  enable  its  early  dissemination  to  comput¬ 
er  systems  designers.  Timeliness  seemed  especially  critical  given  the 
rapidly  changing  state  of  knowledge  and  technology  in  this  domain. 

This  work  was  performed  by  Essex  Corporation  through  a  contract  with 
MacAulay-Brown,  Inc.  under  Air  Force  prime  contract  F33615-82-C-0513.  Dr. 
Kenneth  R.  Boff  was  the  Air  Force  Aerospace  Medical  Research  Laboratory 
Program  Manager.  Mr.  Gian  Cacioppo  was  the  Program  Manager  with  principal 
support  by  Ms.  Judy  Williams  for  MacAulay-Brown,  Inc.  The  Essex  Corpora¬ 
tion  Program  Manager  was  Mr.  Clarence  A.  Semple.  Dr.  Michael  E.  McCauley 
was  the  Essex  Principal  Investigator  for  this  project. 
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INTRODUCTION 


PROGRAM  BACKGROUND 

This  report  is  a  collection  of  Compendium  Entries  on  the  topic  of 
person-computer  dialogue,  written  according  to  a  format  promulgated  by  the 
USAF  Aerospace  Medical  Research  Laboratory  for  a  program  called  Integrated 
Perceptual  Information  for  Designers  (IPID).  The  IPID  program  was  spon¬ 
sored  by  a  multi-agency  effort,  under  the  direction  of  Dr,  Kenneth  R,  Boff 
at  AMRL.  It  was  intended  to  integrate  the  knowledge  (data)  from  experi¬ 
mental  psychology  and  human  factors  engineering  into  a  Compendium  of  brief 
entries  comprising  principles,  models,  or  experimental  results  (Boff, 

1982).  With  extensive  cross  referencing,  this  compendium  would  enable 
design  engineers  to  access  human  factors  information  in  a  convenient, 
condensed  form,  each  entry  being  a  maximum  of  two  pages  in  length.  Ulti¬ 
mately,  the  compendium  is  intended  to  be  available  in  a  computer  data  base 
that  will  be  accessible  to  the  engineer  by  a  "friendly"  interface  to  assist 
in  selecting  appropriate  compendium  entries  for  the  specific  engineering 
task . 


The  human  factors  engineering  portion  of  the  compendium  (as  opposed  to 
the  experimental  psychology  portion)  was  called  the  Human  Engineering  Data 
Base  (HEDB).  Essex  Corporation  was  responsible  for  generating  HEDB  compen¬ 
dium  entries  in  seven  topical  areas: 

•  Information  coding,  portrayal  and  format 

•  Target  detection,  recognition  and  identification 

•  Automation  and  person-computer  function  allocation 

•  Person-computer  dialogue 

•  Feedback,  warning  and  attentional  directors 

•  Controls 

•  Human  performance  reliability 
TOPIC  BACKGROUND 

Person-computer  dialogue  refers  to  the  two-way  exchange  of  information 
between  a  user  and  a  computer.  The  term  dialogue  is  borrowed  from  inter¬ 
personal  communication,  but  at  present,  person-computer  dialogues  are 
considerably  more  limited  than  interpersonal  dialogue.  The  characteristics 
of  person-computer  dialogue,  obviously,  are  attributable  to  the  character¬ 
istics  of  both  the  user  and  the  hardware/ software  system.  The  attempt  to 
provide  system  designers  with  guidelines  for  achieving  good  person-computer 
dialogues  assumes  an  underlying  dimension  of  "goodness"  or  quality  of  the 
dialogue.  Although  "good"  dialogue  is  both  rare  and  perhaps  impossible  to 
achieve,  the  criteria  are  likely  to  be: 

•  Productivity  •  Error  reduction 

•  Efficiency  •  User  satisfaction 

•  Ease  of  use 

Humans  have  a  great  capacity  to  change.  They  adapt,  adjust,  accommo¬ 
date,  acclimatize,  and  learn.  Therefore,  they  are  likely  to  master  nearly 


any  system  interface,  given  the  time  and  motivation.  Unfortunately,  some 
system  designers  rely  heavily  on  the  plasticity  of  human  behavior  and 
deemphasize  the  careful  design  of  the  system's  dialogue  properties. 

METHODOLOGY 

The  Compendium  Entries  in  this  report  were  created  according  to  a 
process  that  involved  the  following  steps:  topic  elaboration,  bibliography 
development,  literature  acquisition  and  review,  development  of  candidate 
entry  listings  (CELs),  review  and  selection  of  CELs  by  an  independent 
panel,  and  expansion  and  integration  of  the  CELs  to  Compendium  Entries. 

Each  Compendium  Entry  was  intended  to  be  a  stand-alone  mini-document 
on  a  specific  topic  area.  Hence,  the  final  report  has  a  loose  organization 
rather  than  one  of  impeccable  continuity.  Furthermore,  the  topics  selected 
and  data  which  have  been  reported  are  limited  by  their  availability  at  the 
time  of  writing.  Since  then,  literally  reams  of  additional  information 
have  been  generated.  Unfortunately,  it  could  not  be  integrated  into  the 
present  report. 

STATUS  OF  GUIDELINES  FOR  PERSON-COMPUTER  DIALOGUE 

While  generating  the  CELs,  the  authors  noted  a  serious  lack  of  em¬ 
pirical  support  for  most  of  the  guidelines  that  have  been  recommended  for 
person-computer  dialogue.  This  lack  of  data  led  the  government  program 
managers  to  recommend  publishing  the  Compendium  Entries  for  the  person- 
computer  dialogue  area  as  a  separate  document;  hence,  this  report. 

There  seem  to  be  two  schools  of  thought  regarding  the  advancement  of 

person-computer  dialogue.  One  emphasizes  the  immediate  need  for  guidelines 
to  support  hardware  and  software  developers,  and  the  other  emphasizes  the 
need  for  solid  empirical  support  before  establishing  guidelines.  At  the 
present  time,  several  sources  of  guidelines  are  available,  although  they 
differ  in  their  currency,  level  of  analysis,  and  system-specificity  (Engel 
and  Granda,  1975;  Ramsey  and  Atwood,  1975;  Smith  and  Aucella,  1983;  Willi- 

ges  and  Williges,  1984).  Several  of  these  studies  did  not  attempt  to 

generate  new  guidelines,  but  to  review  and  consolidate  previous  ones.  The 
present  study  followed  a  similar  process.  The  problem  with  this  method  is 
that  the  caveats  and  constraints  that  may  have  originally  accompanied  the 
guidelines  tend  to  disappear  with  review  and  consolidation.  Consequently, 
a  set  of  guidelines  achieves  a  life  of  its  own,  safely  immune  to  critiques 
of  the  procedures  followed  in  their  development,  the  limits  of  their  appli¬ 
cability  or,  in  some  cases,  a  lack  of  empirical  foundation. 

The  literature  pertaining  to  person-computer  dialogue  (see  Bibliogra¬ 
phy)  is  replete  with  good  ideas,  specific  examples  and  stimulating  dis¬ 
cussion  —  but  not  data.  Solid  empirical  data  that  can  be  generalized  and 
forged  into  design  guidelines  are  very  rare.  The  Keystroke  Model  of  Card, 
Moran,  and  Newell  (1983)  is  one  of  the  few  examples  that  can  be  given  of  a 
model  that  was  derived  from  data  and  validated  against  several  systems. 

Why  are  ideas  so  abundant  but  data  so  sparse  in  the  area  of  person- 
computer  dialogue?  Three  possibilities  are  suggested:  (1)  the  study  of 
PCD  is  a  relatively  new  area  of  endeavor,  arising  only  recently  in  the  wake 
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of  the  microcomputer  "revolution;"  (2)  experimental  procedures  and  method¬ 
ology  are  difficult  in  studying  dialogue  because  of  the  large  number  of 
variables  that  can  apply,  on  both  sides  of  the  interface.  Consequently, 
the  results  of  many  studies  of  person- system  interaction  are  difficult  to 
generalize;  (3)  the  system  development  process  rarely  makes  provision  for 
empiricism.  A  negligible  amount  of  the  total  resources  devoted  to  computer 
system  development  is  allocated  to  research  on  fundamental  issues  in 
human-computer  interaction. 

There  is  a  need  for  a  systems  approach  to  fundamental  research  on 
human-computer  interaction.  Too  often  the  research  is  driven  by  "quick  and 
dirty"  studies  designed  to  answer  a  design  question  relative  to  a  specific 
system.  In  addition  to  this  basic  research,  other  needs  can  be  identified 
from  reviewing  the  literature  in  the  area.  For  example,  who  are  the  design 
guidelines  intended  for  —  design  engineers  or  human  factors  specialists? 
Ideally,  an  interdisciplinary  design  team  would  be  assigned  to  a  system 
development  task.  Team  membership  may  include  expertise  in  hardware, 
software,  human  factors,  artificial  intelligence,  training,  linguistics  and 
cognitive  psychology.  This  interdisciplinary  expertise  could  greatly 
enhance  the  dialogue  properties  of  the  system.  A  related  issue  is  how  the 
characteristics  of  dialogue  should  be  described  in  a  language  that  is 
useful  across  the  disciplines.  Flowcharts,  pseudo-code  and  formal  grammars 
are  candidates  for  providing  a  common  medium  for  communicating  the  func¬ 
tional  design  of  a  dialogue  system.  And  finally,  what  techniques  are 
advisable  for  testing  alternative  dialogue  designs?  It  is  likely  that 
simulation,  modeling  and  field  testing  would  contribute  to  the  refinement 
of  the  dialogue  design.  Further  development  of  such  techniques  seems 
warranted,  particularly  with  respect  to  user  differences  and  variabilities. 

Development  and  validation  of  guidelines,  however,  cannot  be  the  soli¬ 
tary  goal  of  the  future.  A  unified  recognition  of  the  human  factors  con¬ 
cerns  and  interdisciplinary  complexity  of  person-computer  dialogue  must  be 
actively  fostered  between  designers  and  those  in  the  related  disciplines. 

In  surveys  of  system  planners,  designers,  programmers  and  developers, 
there  was  limited  mention  of  four  basic  features  of  human  factors  in  de¬ 
sign:  (1)  Understand  the  user,  (2)  involve  the  user  in  the  design  team, 

(3)  test  the  system  with  typical  users  early  in  the  design  and  (4)  fix 
problems  identified  in  early  testing  through  iterative  design  (Gould  & 
Lewis,  1933).  These  results  indicate  that  the  majority  of  designers  may 
not  be  thoroughly  educated  in  (or  convinced  of  the  utility  of)  these 
issues. 

Gould  and  Lewis  (1983)  Indicate  that  even  when  these  tenets  of  human 
factors  are  acknowledged,  the  understanding  of  them  by  designers  may  differ 
significantly  from  the  original  intent.  What  is  common  sense  to  one  person 
cannot  possibly  be  common  sense  to  another  if  both  parties  do  not  share  a 
mutual  awareness  of  the  vital  issues.  It  appears  critical  that  the  future 
of  research  in  person-computer  dialogue  include  education  of  the  designers 
in  the  utility  of  the  data,  as  well  as  the  applications.  Furthermore,  a 
concerted  effort  must  be  made  to  reduce  the  parochialism  which  exists 
between  designers  and  researchers  of  the  various  disciplines.  Once  this  is 
accomplished,  greater  progress  will  be  made  in  the  field  of  person-computer 
dialogue. 


FUTURE  DIALOGUE  DESIGN 


Future  dialogue  between  people  and  computers  may  expand  considerably 
over  the  limited  dialogue  that  is  now  possible.  Verbal  dialogue,  with 
limited  vocabularies  and  other  constraints  is  possible  now  (McCauley, 

1984),  and  the  long-promised  breakthroughs  in  artificial  intellience  (AI) 
portend  increased  capability  for  the  computer  to  adapt  to  the  character¬ 
istics  of  the  user,  rather  than  vice  versa. 

REPORT  OBJECTIVES 

This  report  may  serve  to  identify  issues  and  gaps  in  our  knowledge  of 
person-computer  dialogue.  It  may  provide  some  useful  guidelines  for  system 
designers,  although  many  caveats  must  be  kept  in  mind.  The  bibliography 
may  serve  as  a  resource  for  those  interested  in  pursuing  the  literature. 
Most  of  all,  we  hope  that  the  report  will  stimulate  research  and  empirical 
validation  of  guidelines  for  person-computer  dialogue. 

This  report  does  not  cover  several  important  areas  of  human-computer 
interaction,  such  as  controls  and  displays  (covered  in  other  topic  areas  of 
the  HEDB  program)  and  human  factors  in  software  development  ( Shneiderman, 
1979). 

It  was  well  beyond  the  resources  of  the  present  project  to  attempt  to 
validate  the  guidelines  reported  herein.  Thus,  we  risk  the  potential  for 
fostering  and  transmitting  guidelines  that  may  be  ill-founded,  only  par¬ 
tially  correct,  or  applicable  only  for  certain  types  of  users  or  systems. 
The  design  engineer  who  reads  this  document  is  advised  to  proceed  with 
caution  and  thoughtful  skepticism. 
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1.  STEPS  IN  PERSON-COMPUTER  DIALOGUE  DESIGN 


KEY  TERMS 

DESIGN  STEPS:  DIALOGUE  DESIGN  STRUCTURE;  DESIGN  PHASES 
GENERAL  DESCRIPTION 

Figure  1  displays  a  systematic  sequence  of  analyses  for  the  design  of  a 
person-computer  dialogue.  In  such  a  system,  the  user  typically  provides 
the  greatest  variability  of  any  system  component.  The  design  of  a 
successful  dialogue-based  system  relies  heavily  on  thorough  systematic 
analyses  from  which  the  needs,  characteristics,  and  capabilities  of  all 
system  components,  including  the  human,  can  be  understood  and  integrated 
into  a  successful  design. 

Analyses  to  determine  the  types  and  characteristics  of  all  potential 
users  must  be  carefully  conducted.  An  erroneous  assumption  is  easily 
made  that  the  designer  already  knows  who  the  user  is;  imperfect  design 
requirements  result.  Steps  2  through  5  specifically  address  the  types 
of  system  users,  their  role  in  the  system,  and  the  user's  capabilities. 

With  full  knowledge  of  the  user  in  mind,  system  hardware/ software  re¬ 
quirements  can  be  established.  Steps  7  through  11,  including  their 
requisite  feedback  loops,  provide  the  opportunity  to  match  the  hardware 
and  software  with  the  needs  and  capabilities  of  the  user  groups.  These 
steps  should  include  the  human  factors  considerations  of  the  hardware 
(i.e.,  operator  comfort,  workspace  layout  and  illumination/CRT  glare), 
as  well  as  system  response  time  and  operator  workload. 

Steps  12  through  16  involve  the  design  of  the  initial  dialogue  structure 
and  support  software,  error  and  failure  control  procedures.  Step  17 
represents  a  critical  design  step,  dialogue  simulation  experiments  prior 
to  actual  coding  of  the  dialogue  software  (Steps  18  to  20).  Participa¬ 
tion  of  the  future  system  users,  at  all  levels,  in  this  aspect  of  the 
design  process  provides  valuable  feedback  to  the  designers  regarding  the 
acceptability  of  the  dialogue  to  the  users.  Furthermore,  user  involve¬ 
ment  at  this  phase  can  "build  in"  a  sense  of  commitment  to  the  new 
system,  easing  potential  negative  acceptance  when  the  system  becomes 
operational . 

"Bullet-proofing",  the  final  step  (Number  21),  is  an  attempt  to  design 
"safety"  features  to  protect  the  system  from  tampering.  Tampering  may 
be  due  to  experimentation,  boredom,  confusion,  or  misunderstanding  of 
the  system  or  dialogue.  It  may  even  be  malicious  and  deliberate.  This 
tampering  can,  in  some  cases,  be  predicted,  given  a  complete  understand¬ 
ing  of  the  user  groups.  Other  potential  problems,  as  well  as  solutions 
to  them,  can  be  identified  in  simulation/system  trials  with  representa¬ 
tive  users.  It  is  critical  that  these  trials  be  performed  with  repre¬ 
sentative  users,  not  sysfem  engineers,  programmers,  etc.  No  matter  how 
open-minded  the  system  designers  are,  only  a  representative  user  can 
react  like  a  real  system  user. 


>  Deumtne  the  purpose  of  the  dteio^ue. 

i 

■  Dcuratnt  ougories  of  user. 

i 

>M111  the  prtae  uitrs  operiu  the  ternlnili  or  contact  tpecUlIzed  operators? 

i 

Deteratnc  the  Inforaatton  flon  structure  and  conf fguratfon  of  operators. 

i 

'Assess  the  capabdittes  of  the  persons  uho  ulU  operau  tne  urafnals. 

Consider  tne  Inforaatlon  bandwidth  chart.  Does  the  dialogue  require  graphics 
or  visual  display  terainals? 

>  Detcralne  the  caugorics  of  dialogue  u  be  used. 
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'Csubllsh  response  tlae  crlurfa. 

'Csubllsh  uralna)  requlreacnts. 

'  Kelate  dialogue  and  response  tiaw  requireaents  to  coaputer  configuration  and 
control  prograa. 

i' 

'  ReUu  uratnal  and  response  ttae  requlreaents  to  coanunicatlon  network 
structure. 

i 

> Design  approalaate  dialogue  structure. 
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Are  dialogue  prograa  generators  avaiiwuic? 

I 

•  Design  detailed  dialogue  structure. 

i 

EsUDllih  error  end  fellurc  control  procedures. 

J' 

Csubllsh  security  procedures. 

i 

’  Set  up  dialogue  slaulatlon  eapertaents. 

i 

Csubllsh  sundards  for  prograenert. 

i 

Csubllsh  prograa  testing  procedures. 


Regin  prograaalng. ' 

'  I 

'lullet-proof*  the  dialogue. 


Figure  1.  Possible  steps  in  dia^logue  design.  (Source:  Martin,  1973) 


APPLICATIONS 


This  approach  will  aid  the  development  of  new  systems  that  may/ will 
include  person-computer  dialogue;  troubleshooting  of  existing  dialogue 
which  is  not  achieving  performance  or  acceptance  standards. 

CONSTRAINTS 

0  Applicability  of  specific  steps  may  vary  with  system  type  or  needs. 
KEY  REFERENCES 

1.  Hendricks,  0.,  Kilduff,  P.,  Brooks,  P.,  Marshak,  R.,  &  Doyle,  B. 
(1982).  Human  engineering  guidelines  for  management  information 
systems.  Alexandna,  VA:  U.^.  Army  Materiel  Detvelopment  and  keadi 
ness  command. 

2.  Martin,  J.  (1973).  Design  of  man-computer  dialogues.  Englewood 
Cliffs,  NJ:  Prentice-l(ai1. 


CROSS  REFERENCES 

2.  Basic  properties  of  person-computer  dialogue;  3.  Comparison  of 
approaches  to  person-computer  dialogue 


2.  BASIC  PROPERTIES  OF  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

INTERACTIVE  DIALOGUE;  INITIATIVE;  FLEXIBILITY;  COMPLEXITY;  INFORMATION 

usm - 


GENERAL  DESCRIPTION 

All  person-computer  dialogues  involve  five  basic  properties  described  in 
Table  1. 

(A)  The  dialogue  is  ''computer-initiated*'  if  the  computer  asks  questions, 
presents  alternatives,  etc.,  and  the  user  responds.  If  the  user  inputs 
commands  without  such  computer  "prompting,"  the  dialogue  is  "user- 
initiated."  Combinations  of  computer  and  user  initiated  dialogues, 
either  "mixed"  or  "variable,"  are  also  possible. 

(B)  Flexibility  is  a  measure  of  the  number  of  ways  in  which  a  user  can 
accomplish  a  given  function.  High  flexibility  can  be  achieved  by  pro¬ 
viding  a  large  number  of  commands,  by  allowing  the  user  to  define  or 
redefine  commands,  etc. 

(C)  Complexity,  related  to  flexibility,  is  a  measure  of  the  number  of 
options  available  to  the  user  at  a  given  point  in  the  dialogue.  Low 
complexity  can  be  achieved  by  us f ng  f ew  c onimalid s ,  or  by  partitioning  the 
commands  so  that  the  user  selects  from  a  small  set  at  any  given  time. 

(D)  Power,  related  to  flexibility  and  complexity,  is  the  amount  of  work 
accomplished  by  the  system  in  response  to  a  single  user  command.  In  a 
dialogue  with  powerful  commands,  the  user  may  accomplish,  with  a  single 
command,  an  operation  which  would  require  several  commands  in  a  system 
with  less  powerful  commands. 

(E)  Information  load  is  a  measure  of  the  degree  to  which  the  interaction 
absorbs  the  memory  and/or  processing  resources  of  the  user. 

APPLICATIONS 

Selection  of  a  dialogue  type  requires  consideration  of  the  five  basic 
properties,  listed  above,  which  dialogue  types  have  in  common  in  order 
to  select  appropriate  dialogue  types. 

CONSTRAINTS 

•  "Mixed  initiative"  or  variable  (user  selectable)  initiative  may  be 
useful  in  situations  involving  varied  user  types. 

t  Selection  of  initiative  mode  must  consider  dialogue  structure  and 
transaction  content  in  addition  to  user  types  and  system  response 
time. 

•  Flexibility  is  difficult  to  measure  in  existing  dialogue  design. 


TABLE  1.  BASIC  DIALOGUE  PROPERTIES  AND  CONSIDERATIONS 
(Source:  Ramsey  &  Atwood,  1979) 


PROPERTY  DESIGN  CONSIDERATIONS  REFERENCES 


A.  Initiative 

COMPUTER  INITIATED: 

0  For  naive  or  casual  users 

0  Relies  on  passive  rather  than  active 
vocabulary 

0  Can  teach  a  “system  model”  to 
unfamiliar  users 

0  Satisfactory  for  experienced  users  if 
system  response  is  fast 

0  Can  constrain  the  amount  of  information 
in  a  transaction 

Ref.  6 

Ref.  7 

Ref.  12 
Ref.  13 

USER  INITIATED: 

0  For  experienced  users 

0  For  frequently  used  actions  or  rapid 
interchanges 

B.  Flexibility 

HIGH  FLEXIBILITY: 

0  For  experienced/ sophisticated  users 

0  Increases  error  rate  of  inexperienced 
users 

0  Results  in  use  of  known  problem-solving 
solutions  rather  than  known,  but 
unlearned,  less  cumbersome  alternatives 

Ref.  4 

Ref.  11 
Ref.  15 
Ref.  16 

C.  Complexity 

0  Optimal  level  is  a  function  of  task  and 
user  type 

0  Deviation  from  optimal  complexity 
results  in  degraded  performance 

0  Redundant  or  irrelevant  commands  impair 
performance 

Ref.  1 

Ref.  2 

Ref.  3 

D.  Power 

0  Must  correspond  to  user's  needs,  which 
can  change  over  time 

0  System  generality  reduces  with  use  of 
powerful  rather  than  less  powerful 
basic  commands 

0  Powerful  commands,  in  conjunction  with 
basic  commands,  increase  complexity 

Ref.  4 

Ref.  11 
Ref.  17 

E.  Information 
Load 

0  Performance  degrades  if  load  is  too 
high  or  too  low 

0  Load  can  be  empirically  measured  or 
estimated 

0  Load  is  a  major  success  factor,  but  not 
often  a  formal  design  consideration 

Ref.  5 

Ref.  8 

Ref.  10 
Ref.  14 

•  Complexity,  as  defined  here,  describes  cognitive  complexity  at 
dialogue  decision  modes,  not  structural  complexity. 

•  No  clear  guidance  on  optimal  complexity  exists  in  the  literature. 

•  Mo  standard  metric  of  dialogue  power  exists. 

•  Measurement  of  workload  and  information  load  may  be  a  problem. 
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CROSS  REFERENCES 


1.  Steps  in  person-computer  dialogue  design 


3.  COMPARISON  OF  APPROACHES  TO  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

DIALOGUE  LANGUAGES;  INPUT-OUTPUT;  DIALOGUE  CATEGORIES 
GENERAL  DESCRIPTION 

Before  selecting  a  particular  dialogue  type  for  a  particular  applica¬ 
tion,  the  characteristics  and  abilities  of  the  user  must  be  accurately 
defined.  Table  2  provides  a  comparison  of  eighteen  approaches  to  inter¬ 
active  dialogue.  For  each  dialogue  type,  advantages  and  disadvantages 
are  noted,  considering  issues  including  limitations/advantages,  user- 
type  effects,  cost  considerations,  and  limitations  of  application. 

Table  3  lists  training  and  system  response  time  requirements  for  the 
major  dialogue  types. 

APPLICATIONS 

Selection  of  interactive  dialogue  type. 

CONSTRAINTS 

Selection  of  dialogue  should  include  consideration  of: 

•  User  characteristics  and  abilities; 

•  Hardware  characteristics  and  limitations; 

•  Information  bandwidth  requirements; 

•  Current  state-of-the-art  technology. 

KEY  REFERENCES 

*1.  Martin,  J.  (1973).  Design  of  man-computer  dialogues.  Englewood 
Cliffs,  NJ:  Prentice-liall . 

2.  Smith,  S.,  &  Aucella,  A.  (1983).  Design  guidelines  for  the  user 
interface  to  computer-based  information  systems.  Bedford,  MA:  The 
miTre  Corporation. 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue  design;  13.  System  response  time 
and  the  effect  on  user  performance  and  satisfaction;  14.  Information 
bandwidth  in  person-computer  dialogue 


♦Principal  reference 
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TABLE  2.  COMPARISONS  OF  INTERACTIVE  DIALOGUES  (Source:  Martin,  1973) 


TYPE  OF  DIALOGUE 

ADVANTAGES 

Programming  languages 

Concise,  precise,  power¬ 
ful,  flexible. 

English-language  dialogue 

Theoretically,  the  most 
natural  man-machine 
interface. 

Limit  English  input 

Users  employ  words  they 
are  familiar  with. 

Question  and  answer  dia¬ 
logues  (in  which  the  com¬ 
puter  asks  the  operator  a 
series  of  questions) 


Very  simple  for  the 
operator.  Can  be  written 
with  a  simple  program. 


DISADVANTAGES 


Inappropriate  for  the 
vast  number  of  terminal 
users  who  have  not 
learned  to  program  and  do 
not  want  to  (e.g.,  man¬ 
agement,  general  public, 
administrative  staff). 


Unsuitable  where  an 
operator's  input  must  be 
interpreted  with  preci¬ 
sion  because  of  the  am¬ 
biguity  of  our  language. 
Immense  software  prob¬ 
lems.  On  commercial 
applications,  it  con¬ 
stitutes  a  trap  to  be 
avoided.  Sometimes  sa¬ 
tisfactory  for  computer- 
assisted  instruction. 


Some  users  tend  to  over¬ 
estimate  the  intelligence 
of  the  machine  and  over¬ 
step  the  tight  restric¬ 
tions  on  input  wording. 


Of  limited  flexibility. 
Suitable  for  certain 
applications  only. 


Dialogue  using  mnemonics 


Dialogue  with  program- 
ming-like  statements 


Computer-initiated  dia¬ 
logues  (in  which  the 
operator  responds  to  the 
computer  rather  than  the 
computer  responding  to 
the  operator) 


Can  be  concise  and  pre¬ 
cise  (e.g.,  airline 
reservation  dialogue). 


Can  be  concise  and  pre¬ 
cise. 


The  computer  tells  the 
operator  what  to  do;  lit¬ 
tle  training  required. 

Can  be  used  with  a  total¬ 
ly  untrained  operator. 


Operator  must  be  familiar 
with  mnemonics  and  for¬ 
mats. 


Operator  must  be  well 
trained,  familiar  with 
the  coding,  and  have  a 
limited  programming  apti¬ 
tude. 


Dialogue  can  be  lengthy 
and  often  slow.  Many 
characters;  high  line 
utilization;  more  expen¬ 
sive  networks.  Little 
flexibility  in  sequence 
of  operation. 


TABLE  2.  COMPARISONS  OF  INTERACTIVE  DIALOGUES  (Source:  Martin,  1973)  (Cont.) 


TYPE  OF  DIALOGUE 


Form-filling  (in  which 
the  operator  fills  out  a 
"form"  on  a  visual  dis¬ 
play) 


Menu-selection  dialogues 


Build  dialogue  features 
into  special  terminal 
hardware 


Dialogues  with  a  light 
pen  for  input  (or  other 
means  of  pointing  to  the 
screen) 


Fixed-panel  responses  (in 
which  the  computer  re¬ 
sponds  with  one  of  a 
standard  set  of  panels) 


Modifiable-panel  dia¬ 
logues  ( in  which  the 
panels  can  be  modified  by 
the  programs) 


Graphics  using  chart 
di splays 


ADVANTAGES 


Straightforward  for 
operator  except  for 
cursor  manipulations. 


Simple  for  the  operator. 
Can  be  written  with  a 
simple  program  generator. 


The  intent  is  usually  to 
clarify  and  simplify  the 
operator  actions.  A 
similar  effect  could 
often  be  achieved  without 
special  hardware,  how¬ 
ever. 


Simple  form  of  input, 
ideal  for  an  untrained 
operator.  Can  make  a 
complex  dialogue  fast. 


Simple  for  programming. 
The  panels  can  be  stored 
in  devices  away  from  the 
main  computer,  giving  low 
transmission  require¬ 
ments.  In  some  cases, 
panels  with  pictures  may 
be  used. 


Can  also  save  transmis¬ 
sion  requirements. 
Simpler  than  tree-form 
dialogues. 


Very  effective  for  sum¬ 
marizing  information  and 
manipulating  models. 
Ideal  for  many  dialogues 
with  management. 


DISADVANTAGES 


Less  flexible  than  a 
"branching  tree"  of  ques¬ 
tions,  and  error  correc¬ 
tion  procedures  are  less 
easy. 


Limited  in  scope.  Large 
number  of  characters 
used;  more  expensive 
telecommunication  net¬ 
work. 


Expensive.  Inflexible. 
May  restrict  future  de¬ 
velopment. 


Limited  in  scope  unless  a 
keyboard  is  used  as  well 
as  the  light  pen. 


Inflexible. 

scope. 


Of  limited 


Loses  the  simplicity  of 
fixed-panel  dialogues. 


Expensive.  Elaborate 
programming  requirements 
(which  may  be  available 
through  software).  On 
teleprocessing  systems 
"intelligent"  terminals 
are  needed  to  avoid  band¬ 
width  restraints. 


TABLE  2.  COMPARISONS  OF  INTERACTIVE  DIALOGUES  (Source;  Martin,  1973)  (Cont. ) 


TYPE  OF  DIALOGUE  ADVANTAGES  DISADVANTAGES 


Graphics  using  symbol 
manipulation 

Very  effective  for  com¬ 
plex  problem  solving, 
engineering  design,  etc. 

Expensive.  Elaborate 
programming  requirements. 
"Intelligent"  terminals. 

Dialogues  with  photogra¬ 
phic  frames 

Photographs  are  valuable 
in  certain  applications 
(e.g.,  real  estate,  per¬ 
sonnel,  engineering, 
parts,  systems  used  by 
children).  They  may  be¬ 
come  extensively  used 
when  home  CATV  terminals 
come  into  use. 

Telecommunication  chan¬ 
nels  in  use,  other  than 
CATV,  have  insufficient 
bandwidth  for  photograph 
transmission.  The  images 
must  therefore  be  stored 
at  the  terminal  location. 

Voice  answerback  dia¬ 
logues 

The  telephone  is  the 
cheapest  available 
terminal . 

Limited  in  what  can  be 
accomplished. 

Dialogue  via  a  third 
party 

Many  important  uses 
(e.g.,  information  room, 
data  secretaries,  tele¬ 
phone  agents,  counter 
clerks).  Enables  manage¬ 
ment  and  the  general  pub¬ 
lic  to  obtain  information 
from  computers. 

Generally  prevents 
extended  use  of  the 
terminal . 

TABLE  3.  TRAINING  AND  RESPONSE  TIME  REQUIREMENTS  FOR  SELECTED 
DIALOGUE  TYPES  (Source:  Smith  &  Aucella,  1983) 


DIALOGUE  TYPE 

REQUIRED 

USER  TRAINING 

REQUIRED  SYSTEM 
RESPONSE  TIME 

Question  and  Answer 

Li ttle/None 

Moderate 

Form  Filling 

Moderate/Li ttle 

Slow 

Menu  Selection 

Li ttle/None 

Very  Fast 

Function  Keys  with  Command 
Language 

High/Moderate 

Fast 

User-Initiated  Command 
Language 

High 

Fast 

Query  Languages 

High/Moderate 

Moderate 

Natural-Language  Dialogues 

Moderate  (poten¬ 
tially  little) 

Fast 

Interactive  Graphics 

High 

Very  Fast 

4.  MAJOR  DATA  MODELS  IN  DATA  BASE  SYSTEMS 


KEY  TERMS 

DATA  BASE;  TAXONOMY;  CENTRALIZATION;  USER  TYPES;  DATA  TYPES;  DATA 
MODELS:  EXPLICIT  AND  IMPLICIT;  RELATIONAL  MODELS;  HIERARCHICAL  MODELS; 
NETWORK  MODELS;  QUERY  LANGUAGE;  COMPUTER  SYSTEM  MODELS;  MODELS  Of"  HUMAN 
INFORMATION  PROCESSING 

GENERAL  DESCRIPTION 

Data  base  systems  are  composed  of  three  separate,  yet  interactive  compo¬ 
nents:  users,  centralized  data,  and  centralized  interface.  Centraliza¬ 
tion  is  the  key  concept  which  reduces  data  duplication  and  facilitates 
enforcement  of  data  integrity  and  security  controls.  Centralization 
creates  an  independence  of  data.  The  diversity  of  potential  users  makes 
it  vital  to  tailor  the  interface  to  the  appropriate  user  group. 

The  centralized  interface  is  the  system  component  in  which  human  factors 
optimization  includes  selection  of  a  query  language  which  is  appropriate 
to  the  type  of  user  and  data  model.  As  shown  in  Table  4,  Implicit  Data 
Models  must  also  include  human  factors  considerations  including  optimi¬ 
zation  of  natural-language  dialogues,  screen  layouts  and  number  of  menu 
items.  Query  languages  for  the  implicit  data  model  facilitate  use  by 
novice  or  nontechnical  users.  Explicit  Data  Models  are  more  suitable 
for  use  by  professional  progranwners.  The  relational  model  (Ref.  3) 
utilizes  a  tabular  structure  in  which  the  columns  contain  values  from  a 
single  domain.  Hierarchical  models  organize  data  elements  into  a  tree 
structure.  Network  models  (Ref.  1)  group  data  elements  into  records, 
which  are  organized  into  data- structure  sets  via  use  of  pointers. 

APPLICATIONS 

Data  base  systems;  data  base  design;  subschema  design. 

CONSTRAINTS 

Selection  of  a  data  model  requires  consideration  of: 

•  Type  of  user 

•  Logical  organization  of  data 

•  Perception  of  data  organization  by  potential  users  (Ref.  5) 

•  Human  factors  criteria,  including  simplicity,  elegance,  picturabili- 
ty,  modeling  directness,  overlap  with  co-resident  models,  partition- 
ability  of  data,  and  nonconflicting  terminology  (Ref.  7) 

•  Selection  of  variable  names  to  ensure  comprehension  by  users. 

User  confusion  can  result  from: 

e  Restricted  and  formal  meaning  of  common  English  words 

•  Misinterpretations  of  application-domain  limitations  when  unre¬ 
stricted  natural  language  is  used 

•  High  number  of  relations  in  relational  data  models;  fewer  relations 
with  more  columns  can  reduce  query  complexity 
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TABLE  4.  INTERFACE  COMPONENT  OF  DATA  BASE  SYSTEMS 


8.  UpllcU  OiU  Hotels  (froa  Shntltermin.  1960) 

•  teUttonil 

SKl-RESOKTS  11  RCSODT-NAME  I  STAU  I  VCRTICAL-OROP 


TRAILS  RESORT-NAME 

TRAIL-NAME 

OlFTICULTY 

CxMpU  schcai  dUgrM  for  rtlatloMi  teUtesc. 


PATIOLLEK-NAME 


Cxanplf  sch'jM  dU9r«a  for  M«r«rch1c4l  Information  teutese. 


•  Network 


CHARACTERISTICS 


Dots  not  provide  loglcdl  view  of 
tete  to  user. 

Involves  knowled9e  of  oppllcotlon 
ore*  rether  tten  teti  coapononts. 


Avoids  loploaenutlon  deUlls. 
Rroaotes  teto  Intependence. 
Seporstcs  logical  and  physical  data 
Issues > 


SKI -PATROLLERS  |{  RCSORT-NAtC  I  TRAIL-HAHE  I  PATROLLER-NAME  I  SHIFT  I  ACE 


0  Hierarchical 

SKI-NEAORTS 

1  resortname 

STATE  1  VERTICAL'DROP| 

tiaju 

um\ 

|tiUIL-HaMe[  DIFFICULTY  | 

(urr^^AAfcj  TYPE  1 

IKl#AT1tOLUU  1 

Easy  to  understand. 

Halts  coaplexity  of  data  rtU> 

tIOAShIpS. 

Allows  *0Ae  to  aany*  relationships 


QUERY  LANGUAGE  TYPE 


Natural  Language 
0  Staple  English 
0  Psuedo  English 
a  EngMsh'llke 

Coaputer  Initiated 
0  Nenu  selection 
e  Question  i  answer 
0  Paraaeter  specification 


Includes  additional  features  for: 

•  Organizing  Inforaatlon 

•  Searching  efficiently 

>  Storing  records 

>  Controlling  privacy 
-  Checking  Integrity 

•>  Facilitating  data  aantnlstratlon 
Allows  *Biany  to  aany*  relationships. 


Host  aapedded  data  aanipulatlon  Un> 
guages*  including: 

-  PL/ 1 

•  CoOol 

•  Fortran 

•  AsswOler 


Caaaple  schaaa  diagraa  for  network<«ote1  database 
with  LINKS  and  RANKS  Inforaatlon. 


0  Inadequate  "depth  versus  breadth"  trade-offs  in  hierarchical  data 
model s 

0  Use  of  records  with  multiple  owner  record  types  and  cyclic  schema  in 
network  data  models. 

KEY  REFERENCES 

1.  Brosey,  M.  K.,  &  Shneiderman,  B.  (1978).  Two  experimental  compari¬ 
sons  of  relational  and  hierarchical  data  base  models.  International 
Journal  of  Man-Machine  Studies,  10,  625-637. 

2.  cOOasyl  OBYg.  (1971).  cOdASYL  daTa  base  task  group  report,  Confer- 
ence  Data  Systems  Languages.  Mew  York,  MY:  Association  for  tom- 
putinci  Machinery. 

3.  Codd,  E.  F.  (1970).  A  relational  model  of  data  for  large  shared 
data  banks.  Communications  of  the  ACM,  13(6),  377-387. 

4.  Date,  C.  .1.  (157771  An  Introduction  to  cTatabase  systems  (2nd  Ed.). 
Reading,  MA:  Addison-Westey. 

5.  Ourding,  8.  M.,  Becker,  C.  A.,  S  Gould,  J.  D.  (1977).  Data  organi¬ 
zation.  Human  Factors,  1~1A. 

*6.  Greenblatt,  0.,  &  Waxman,  J.  (1978).  User  oriented  query  language 
design.  In  Proceedings  of  the  Human  Factors  and  Computer  Science 
Symposium  (pp.  78-102).  Santa  Monica,  CA:  Human  factors  Society. 

7.  McGee,  W.  C.  (1976).  On  user  criteria  for  data  model  evaluation. 

ACM  Transactions  on  Database  Systems,  1(4),  370-387. 

8 .  Ramsey,  H.  K.,  &  Atwood,  M.  L.  ti9/9) .  Human  factors  in  computer 
systems;  A  review  of  the  literature  (SAI-79-111-DEN) .  Englewood, 
11^(7  Science  Applications,  Inc.  (NtlS  AD  A075  679) 

*9.  Shneiderman,  8.  (1980).  Software  psychology:  Human  factors  in  com¬ 
puter  and  information  systems.  Cambridge,  MA:  Hinihrop  Publishers. 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue;  2.  Basic  properties  of  person 

computer  dialogue 


♦Principal  reference 


5.  TECHNiqUES  FOR  MODELING  INTERACTIVE  SYSTEMS 


KEY  TERMS 

SYSTEM  MODELING;  SIMULATION 
GENERAL  DESCRIPTION 

Five  approaches  to  modeling  Interactive  systems  are  discussed  In  Table 
5.  Section  (A)  describes  network  models  Intended  to  define  the  rela¬ 
tionships  between  system  and  user  tasks  In  terms  of  expected  performance 
and  logical  predecessor-successor  relationships;  (B)  models  based  on 
control-theory,  statistical  estimation,  and  decision  theory  which  regard 
users  as  feedback  loop  elements;  (C)  decision- theory  models  which  allow 
selection  of  courses  of  action  based  on  users'  decision-making  behav¬ 
iors;  (0)  models  of  human  Information  processing  which  analyze  the 
problems  to  be  solved  and  protocols  used  by  problem- sol  vers  during  solu¬ 
tion;  and  (E)  computer  system  models  which  describe  only  the  computer 
component  behavior  of  Interactive  systems  but  do  not  model.  In  detail, 
the  behavior  of  users. 

APPLICATIONS 

Examination  of  the  effects  of  alternative  design  decisions  prior  to 
selection  of  appropriate  dialogue  design;  evaluation  of  user  and  task 
properties. 

Network  Models 

•  Linear  tasks  -  single  or  multiple  path 

Control -Theory  Models 

•  Control -type  tasks 

•  Tasks  with  use  of  well-learned  algorithms/ procedures 
Decision-Theory  Models 

•  Tasks  with  selection  of  alternatives  and  evaluating  outcomes 

Models  of  Human  Information  Processing 

•  Tasks  with  human  as  Information  processor 

•  Models  exist  for  well-specified  tasks  where  complete  model  Is 
not  necessary 

Computer  System  Models 

•  Descriptions  of  computer  behavior 

•  Determining  If  user  requlranents  are  satisfied 

•  Optimizing  overall  performance  In  existing  systems 


TABLE  5.  OVERVIEW  OF  INTERACTIVE  SYSTEM  MODELING  TECHNIQUES 
(Source:  Ramsey  &  Atwood,  1979) 


APPROACH 

CHARACTERISTICS 

REFERENCES 

A.  Network 
Models 

Usually  used  to  predict  either  the  pro¬ 
bability  of  failure  or  "success,"  or 
the  completion  time,  of  an  aggregate 
set  o'"  tasks. 

Ref.  1 

Ref.  6 

Ref.  9 

Allow  performance  data  about  user  and 
computer  system  to  be  integrated  irr  a 
single  model  even  though  original  data 
came  from  a  variety  of  sources. 

B.  Control- 
Theory 

Model s 

Usually  used  to  predict  overall  per¬ 
formance  of  the  user-computer  system 
in  continuous  control  and  monitoring 
tasks. 

Ref.  6 

More  quantitative  than  other  perfor¬ 
mance  models,  but  ordinarily  do  not 
deal  with  details  of  the  interface, 
such  as  display  design. 

C.  Decision- 
Theory 

Model s 

Can  be  used  to  suggest  "optimal"  deci¬ 
sions  or  to  describe  the  observed 
decision-making  behavior  of  users. 

Ref.  6 

Frequently  used  in  decision  aids. 

D.  Models 
of  Hunan 
Information 
Processi ng 

Ideally  lead  to  an  integrative  model 
of  human  information  processing  use- 
able  in  a  variety  of  design  applica- 
cations. 

Ref.  5 

Ref.  6 

Ref.  10 

Existing  models  may  be  applicable  to 
very  specific  tasks,  if  recognized  as 
relevant. 

E.  Computer 
System 

Models 

Can  be  useful  in  determining  whether 
or  not  user  requirements  with  respect 
to  response  time  and  other  gross 
system  performance  measures  can  be 
satisfied  by  a  proposed  system. 

Ref.  2 

Ref.  3 

Ref.  4 

Ref.  3 

Usually  attempt  to  predict  such  per¬ 
formance  factors  as  system  response 
time,  CPU  and  memory  loads,  and  I/O 
requirements. 

CONSTRAINTS 


Development  of  interactive  system  models,  in  general,  is  limited  by  the 

following: 

0  Models  based  on  memory  and  process  limitations  are  restricted  to 
simple  tasks  due  to  high  detail  demands. 

0  Validation  of  models  used  as  dialogue  design  tools  may  not  be  prac¬ 
tical  . 

0  Successful  models  have  been  limited  to  simple  task  domains. 

0  Designer  must  thoroughly  understand  the  task  domain  and  information 
requirements. 

0  No  general  approach  to  model  development  exists. 

0  Other  types  of  user-alone  models  exist,  not  yet  adapted  to  inter¬ 
active  systems. 

KEY  REFERENCES 

1.  Baker,  J.  D.,  &  Goldstein,  I.  (1966).  Batch  vs.  sequential  dis¬ 
plays:  Effects  on  human  problem  solving.  Human  Factors,  8,  225- 
235. 

2.  Carbonell,  J.  R.  (1967).  On  man- computer  interactions:  A  model  and 
some  related  issues  (BBN  Report  No.  1593).  Cambridge,  MA:  Bol t, 
Seranek  and  Newman,  Inc.  (Also  reported  more  briefly  in  IEEE  Trans- 
actions  on  System  Science  and  Cybernetics,  1969,  SSC-5,  lS-26. ) 

CRfTrS  Ho.-  AD  -556655) - - 

3.  Foley,  0.  D.  (1971).  An  approach  to  the  optimum  design  of  computer 
graphics  systems.  Communications  of  the  ACM,  14,  380-390. 

4.  Grignetti,  M.  C.,  Miller,  'D.  C.,'  N-Iclcerson,  R.T. ,  &  Pew,  R.  W. 
(1971).  Information  processing  models  and  computer  aids  for  human 
performance:  Task  2:  Human-computer  interactions  models  (AFOSR- 
TR-)1-2845) .  tanibri'cfge,  HA:  Bolt,  Seranek  and  tJewman,  Inc.  (NTIS 
No.  AO  732913) 

5.  Mann,  W.  C.  (1975).  Dialogue-based  research  in  man-machine  communi¬ 
cation  (ISI  RR-75-41)'!  Marina  del  Rey,  CA:  University  o'f  Southern 
California,  Information  Sciences  Institute. 

6.  Pew,  R.  W.,  Baron,  S.,  Feehrer,  C.  E.,  &  Miller,  0.  C.  (1977). 
Critical  review  and  analysis  of  performance  models  applicable  to 
man-machine  systems  evaluation  (Report  )jo.  3446).  Cambridge,  MA: 
Bolt,  deranek  and  Wewman,  (nc.  (NTIS  No.  AD  A038597) 

*7.  Ramsey,  H.  R.,  &  Atwood,  M.  E.  (1979).  Human  factors  in  computer 
systems:  A  review  of  the  literature  (SAI-79-111-DEN) .  Englewood, 
'UP.  Science  Applications,  Inc.  TTITlS  No.  AD  A075679) 

8.  Shemer,  J.  E.,  S  Heying,  D.  W.  (1969).  Performance  modeling  and 
empirical  measurements  in  a  system  designed  for  batch  and  time¬ 
sharing  users.  AFIPS  Conference  Proceedings,  35,  17-26. 

9.  Siegel,  A.  I.,  Wolf,  J.  J.,  S  Leahy,  W.  R.  (1973).  A  digital  simu- 
lation  model  of  message  handling  in  the  Tactical  Operations  System: 
T.  The  mode  I ,  its  sensitivity ,  and  users  manual  (Research  Memoran 
dum  73-5) .  Arlington,  VA:  D.  S.  Army  Research  Institute  for  the 
Behavioral  and  Social  Sciences. 


♦Principal  reference 


10.  Zeigler,  B.  P.,  &  Sheridan,  T.  B.  (1965).  Human  use  of  short-term 
memory  in  processing  information  on  a  console.  IEEE  Transactions  on 
Human  Factors  in  Electronics,  HFE-6,  74-83. 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue  design;  6.  Keystroke  model  for 
predicting  task  execution  time;  7.  A  protocol  analysis  for  documenting 
user  problems  with  interactive  systems;  8.  Formal  language  as  a  design 
tool  for  person-computer  dialogue;  9.  Playback  methodology  for  evaluat¬ 
ing  person-computer  dialogue;  10.  Interface  design  principles  derived 
from  human  error  analyses 
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6.  KEYSTROKE  MODEL  FOR  PREDICTING  TASK  EXECUTION  TIME 


KEY  TERMS 

RESPONSE  TIME;  TASK  COMPLETION;  KEYBOARD  INPUT 
GENERAL  DESCRIPTION 

The  Keystroke  Model  estimates  the  time  required  for  an  expert  user  to 
accomplish  a  given  task  using  an  interactive  computer  system.  Task 
execution  time  is  described  in  terms  of  four  physical-motor  operators 
(K,  P,  H  and  D),  one  mental  operator  (M)  and  one  system  response  opera¬ 
tor  (R).  Table  6  describes  the  operators.  Rules  for  placing  the  M- 
operations  are  defined  in  Table  7.  An  encoding  method  is  given  for 
specifying  the  series  of  operators  in  a  task  prior  to  applying  the 
equation: 


execute 


=  T„  +  T.^  +  T,,  +  T^  +  T..  +  Jr 


The  Keystroke  Model  has  been  validated  against  eleven  systems,  with  the 
calculated  and  observed  times  for  task  execution  shown  in  Figure  2. 


TABLE  6.  DESCRIPTIONS  OF  THE  OPERATORS  IN  THE  KEYSTROKE  MODEL 


OPERATOR 

DESCRIPTION 

TIME  (sec) 

K 

Press  key  or  button  (includes  shift  or  control 
keys).  Time  varies  with  skill: 

Best  typist  (135  wmp) 

.08 

Average  typist  (55  wmp) 

.20 

Typing  complex  codes 

.75 

Worst  typist 

1.20 

P 

Point  with  mouse  to  target  on  display  (follows 
Fitt's  Law,  range  .8  to  1.5  sec.) 

1.10 

H 

Home  -  hands-on  keyboard  (or  other  device) 

.40 

D  (n^,  Ij) 

Draw  n^  straight-line  segments  of  total  length 

1  .  cm  (assumes  drawing  straight  lines  with  a 

mouse 

.9nd  +  .161^ 

M 

Mentally  prepare  (see  Table  7  for  application 
rules) 

1.35 

R  (t) 

Response  by  the  system  (only  if  it  causes  the 
user  to  wait) 

t 

TABLE  7.  RULES  FOR  PLACING  THE  M  OPERATIONS 
(Source:  Card,  et  al.,  1983) 


All  physical  operations  and  response  operations  must  be  encoded.  Use 

Rule  0  to  place  candidate  M's,  then  cycle  through  Rules  1  to  4  for 

each  M  to  see  whether  it  should  be  deleted. 

Rule  0.  Insert  M's  in  front  of  all  K's  that  are  not  part  of  argument 
strings  proper  (e.g.,  text  or  numbers).  Place  M's  in  front 
of  all  P's  that  select  commands  (not  arguments). 

Rule  1.  If  an  operator  following  an  M  is  fully  anticipated  in  an 

operator  just  previous  to  M,  then  delete  the  M  (e.g,,  PMK  — ^ 
PK) . 

Rule  2.  If  a  string  of  MKs  belongs  to  a  cognitive  unit  (e.g,,  the 
name  of  a  command),  then  delete  all  M's  but  the  first. 

Rule  3.  If  a  K  is  a  redundant  terminator  (e.g.,  the  terminator  of  a 
command  immediately  following  the  terminator  of  its 
argument),  then  delete  the  M  in  front  of  it. 

Rule  4.  If  a  K  terminates  a  constant  string  (e.g.,  a  command  name), 
then  delete  the  M  in  front  of  it;  but  if  the  K  terminates  a 
variable  string  (e.g.,  an  argument  string),  then  keep  the  M 
in  front  of  it. 


Texi  ednofs 


•  POET 
■  SOS 
▲  BRAVO 

Gf  phics  •diiofs 

O  MARKUP 
□  DRAW 
^  SiL 

EMecalive  9ub»ysigms 
4  am  tubiysiems 


30  AO  50 


Predicied  Execution  Time  (sec) 


Figure  2.  Observed  execution  times  versus  predicted 
times  by  the  Keystroke  Model. 

(Source;  Card,  Moran  and  Newell,  1983) 


APPLICATIONS 


Has  been  used  to  predict  execution  times  in  (1)  text-editing;  (2)  com¬ 
puter-graphics  tasks  and  (3)  system- executive  tasks.  Can  be  applied 
directly  to  tasks  which  are  accomplished  at  a  computer  terminal  using  a 
keyboard  and/or  a  mouse. 

Method  of  Application 


Given:  A  task  (involving  a  sequence  of  subtasks;  the  command  language 
of  a  system;  the  motor  skill  parameters  of  the  user;  the  response  time 
parameters  of  the  system;  and  the  method  used  for  the  task). 

The  Keystroke  Model  will  predict:  the  time  an  expert  user  will  take  to 
execute  the  task  (not  including  errors). 

An  example  application  is  a  text  editing  task  of  replacing  a  five-letter 
word  with  another  five-letter  word,  one  line  below  the  previous  modifi¬ 
cation: 


System  A 


System  B 


Jump  to  next  line 

MKELINEFEED] 

Reach  for  mouse 

HCmouse] 

Issue  Substitute 
command 

MK[S] 

Point  to  word 

P[word] 

Type  new  5-letter 
word 

5KCword] 

Select  word 

KCYELLOH] 

Terminate  new  word 

MKC RETURN] 

Home  on  keyboard 

HC keyboard] 

Type  old  5-letter 
word 

5KCword] 

Issue  Replace 
command 

MK[R] 

Terminate  old  word 

MKCRETURN] 

Type  new  5- letter 
word 

5K[word] 

Terminate  command 

KCRETURN] 

Terminate  type-in 

MKCESC] 

Using  the  operator  times  from  Figure  2,  and  assuming  an  average 
typing  speed  (tj^  =  .2  sec): 

System  A  Execution  Time:  =  2tj^j  +  8t^  +  2tj^  * 

System  B  Execution  Time:  ^g^ecute  ~  ~ 

EMPIRICAL  VALIDATION 

The  Keystroke  Model  was  evaluated  by  comparing  calculated  and  observed 
execution  times  in  ten  systems  using  14  tasks,  28  operators  and  1230 
user-system-task  interactions.  The  systems  Included  three  text  editors, 
three  graphics  systems  and  four  executive  subsystems. 
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The  data  from  the  validation  studies  are  shown  in  Figure  2,  comparing 
the  predicted  and  observed  task  execution  times.  The  root-mean-square 
error  was  21J. 


CONSTRAINTS 

•  The  model  applies  to  the  behavior  of  experienced  users.  Experienced 
users  have  lower  variability.  Mo  metrics  are  available  for  low  or 
moderately  experienced  operators. 

•  The  model  assumes  error-free  performance. 

•  Proper  task  analysis  and  encoding  are  prerequisites. 

•  Tasks  that  require  acquisition  time  {to  perceive,  read  or  interpret 
displayed  information)  are  not  covered  directly  by  the  Keystroke 
Model . 

•  With  highly  repetitive  tasks,  users  reduce  their  mental  time  below 
the  model's  predictions  (M). 

«  The  model  does  not  apply  to  tasks  that  emphasize  mental  operations, 
such  as  composing  text. 

KEY  REFERENCES 

1.  Card,  S.  K.,  Moran,  T.  P.,  &  Newell,  A.  (1980).  The  keystroke  level 
model  for  user  performance  time  with  interactive  systems.  Communi¬ 
cations  of  the  ACM,  n,  396-410. 

*2.  Card,  S.  K.,  Moran,  T.  P.,  4  Newell,  A.  (1983).  The  psychology  of 
human-computer  interaction.  Hillsdale,  NJ:  Lawrence  Erlbaum. 


CROSS  REFERENCES 

7.  A  protocol  analysis  for  documenting  user  problems  with  interactive 
systems;  8.  Formal  language  as  a  design  tool  for  person-computer 
dialogue 
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*Principal  reference 


7.  A  PROTOCOL  ANALYSIS  FOR  DOCUMENTING  USER 
PROBLEMS  WITH  INTERACTIVE  SYSTEMS 


KEY  TERMS 

PERSON-COMPUTER  DIALOGUE;  SYSTEM  DOCUMENTATION;  USER  PERFORMANCE;  SYSTEM 

performance 

GENERAL  DESCRIPTION 

Protocol  analysis  provides  identification  and  documentation  of  cognitive 
mismatch  between  human  and  computer  in  interactive  systems.  This  meth¬ 
odology  involves  a  formalized  interactive  session  during  which  terminal 
protocols  (user  performance)  and  verbal  protocols  (user-expressed  cogni¬ 
tive  activity)  are  observed  and  recorded.  Both  protocols  provide  com¬ 
plementary  information:  terminal  protocol  describes  directly  observable 
user  behaviors  and  verbal  protocols  describe  concurrent  thought/ reason¬ 
ing  processes  or  cognitive  activities  occurring  during  periods  of  no 
observable  user  behaviors.  Collectively,  the  two  protocols  provide  data 
from  which  hypotheses  of  user-computer  mismatch  can  be  formulated  for 
empirical  resolution. 

The  protocol  analysis  must  fulfill  two  needs:  (1)  recording  of  proto¬ 
cols  and  (2)  classification  of  protocols.  During  the  session,  the 
system  user  must  be  required  to  describe  the  aim  and  the  expected  system 
response  before  entering  each  command.  Use  of  documentation  or  taking 
of  notes  by  the  system  user  is  not  allowed. 

The  experimenter  must  merge  the  two  protocol  streams  into  a  single 
recording  of  the  session,  since  the  two  are  either  concurrent  or  se¬ 
quentially  occurring.  Distinctions,  however,  are  maintained  between 
problems  in  terminal  protocol  and  verbal  protocol.  Problems  deduced 
from  terminal  protocol  are  referred  to  as  errors,  those  deduced  from 
verbal  protocol  (or  from  both  sources)  are  di f fTcul ties,  and  those  from 
recollections  of  previous  difficulties  or  errors  are  remi ni scences . 

Each  of  these  classifications  are  used  to  categorize  interactive  events. 
An  example  protocol  session  is  provided  in  Table  8,  including  the  keys 
for  the  protocol  recording.  To  facilitate  ease  of  collection  and  cate¬ 
gorization,  protocol  observation  data  are  coded  in  accordance  with  a 
standardized  criterion. 

APPLICATIONS 

Documentation  of  person-computer  interface  mismatch;  hypothesis  genera¬ 
tion  for  empirical  research;  validation  of  models. 

Method  of  Application 


Example  of  System  Evaluation: 

The  most  common  cause  of  error  was  mistyping  (33%  of  all  errors). 
Further  analysis  showed  that,  with  the  majority  of  errors  (51%),  the 


TABLE  8. 


SAMPLE  PROTOCOL  ANALYSIS 


(Source:  Hammond,  et  al . ,  1980) 


Example: 

Person-Machine  Interaction 


Section  1.3.1 

S:  Now,  I  can't  remember  the  format  of  aver¬ 
age,  #  It's  A  V  G  E  or  something.  I'll  try  It 
out  anyway.  Sounds  logical.  No,  I  don't 
think  we  should  have  an  E,  we'll  just  try  A  V 
G.  And  we'll  say  PEOPLE  and  it'll  probably 
fall. 

#10;20;53:  ?:  *T<-<:AVE:AGE;>PEOPLE 

State:  Waiting  with  OUTPUT  flag 


Protocol  Recording 


^Language:  Lexical  (D  N+ 


#Language:  Syntax  (E  N+  M+ 
<Syntax  appropriate  for 
<operators  rather  than 
<functions 


Section  1.3,2 

S:  What  has  happened,  output,  #  it  worked, 
my  goodness.  Hang  on,  what  has  happened? 
Now  I've  got  a  message  up  here. 

(ENTER  pressed  here 

10:20:55:  <AVG:AGE;>  -  ILLEGAL  MONADIC 

OPERATOR 

10:21:00:  MESSAGE  ID  118 
State:  Prompt  with  blank  field 

Section  1.3.3 

S:  Illegal  monadic  operator. 

§  I  don't  know  whether  that's  a  mistake 
for  nomadic  or  not... 


^Language;  interpretation  (D  N- 
<Interpreted  OUTPUT  as  implying 
<correct  solution 


ILanguage:  Interpretation  (D  N+ 


Key  to  System  and  Task  Characteristics  (Specific  to  system  under  analysis;  may  require 
-  modification  as  application  changes.) 

-  The  workplace  environment:  Comfort,  lighting  and  noise. 

-  The  terminal  keyboard:  Keying  errors,  confusions  and  delays. 

-  The  terminal  display:  Legibility  and  formatting. 

-  General  system  operating  characteristics:  Control  of  the  terminal,  system  response 
time,  allocation  of  space. 

-  The  interactive  language:  Lexical,  syntactic  and  semantic. 

-  The  interactive  language:  Interpretation  of  system  responses, 

-  Task  organization  influenced  by  the  system:  Imposed  goal  structures. 

-  Task  organization  independent  of  the  syvEem:  Conditions  of  the  study. 


Key  to  Symbols  Used  in  Protocol  Observations 

t  »  event  categorizations 
(e  ■=  errors 
(d  “  difficulties 
(r  =  reminiscences 

M+  *  created  system  error  message 
M-  »  no  system  message  generated 
N+  =  noted  by  user  before  or  when  occurred 
N-  =  unnoted  by  user 
<  •  explanatory  comments 

State  «  definition  of  system  state  after  a  user  input 
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correct  key  was  pressed  but  in  the  wrong  shift.  Subjects  identified 
this  as  a  problem:  "I  definitely  think  the  worst  thing  about  this  is 
the  amount  you  have  to  use  the  shift  key."  This  is  clearly  an  issue 
that  could  have  been  discovered  at  the  design  stage  had  an  evaluative 
study  been  performed.  The  probable  remedy  would  lie  in  changing  the 
character  set. 

The  chronicled  events  can  also  provide  input  for  Hypothesis  Generation 
of  models.  One  model,  termed  Block  Interaction  Model,  analyzes  the 
separable  classes  of  knowledge  In  the  user's  head  which  he  draws  upon 
during  the  interaction.  Classes  of  knowledge  include  his  representation 
of  the  problem,  knowledge  of  the  system,  general  knowledge  of  other 
systems,  natural  language,  and  so  on.  Note  that  this  differs  from  the 
categorization  scheme  which  deals  only  with  system  knowledge.  The  Block 
Interaction  Model  defines  the  possible  forms  of  interference  between  the 
classes  of  knowledge. 

A  Goal  Structure  Model  allows  representation  of  the  planning  behind  a 
sequence  of  dialogue  and  predicts  the  occurrence  of  certain  classes  of 
error  at  certain  stages  in  the  dialogue.  Likewise,  the  user's  internal 
representation  of  the  state  of  the  machine  and  how  it  changes  with  user 
actions  can  be  contrasted  with  the  true  state  of  the  machine  by  means  of 
representation  derived  from  a  Staite  Transition  Model.  The  identifica¬ 
tion  of  system  states  particularly  prone  to  error  has  consequences  for 
the  type  of  feedback  that  the  system  should  present  to  the  user,  for 
example,  which  states  should  be  defined  by  display  flags. 

The  Information  Processing  Model  calls  upon  current  models  in  cognitive 
psychology  dealing  with  relevant  processes,  such  as  language  analysis 
and  production,  information  storage  and  retrieval,  and  keyboard  skills. 

A  prediction  of  information  storage  models  is  that  an  item  which  is 
conf usable  with  other  items  or  which  cannot  easily  be  discriminated  from 
them  will  be  difficult  to  use  and  remember.  Multiple  use  of  the  same 
character  for  different  purposes  is  an  example  of  a  potential  source  of 
confusions  which  could  be  used  to  explore  the  model. 

CONSTRAINTS 

0  System  user  must  be  capable  of,  and  willing  to,  verbalize  the  rea¬ 
soning  associated  with  system  usage. 

0  Requires  interpretation  by  the  researcher  of  system  users'  verbal 
reports. 

0  User  reports  may  be  incomplete;  information  which  is  obvious  to  user 
may  not  be  verbalized. 

0  Possibility  exists  that  problem-solving  may  be  affected  by  concur¬ 
rent  verbalizations  (Ref.  5). 

0  Tasks  to  be  performed  by  system  users  will  be  determined  by  the 
purpose  of  the  study. 

0  Observational  studies  on  existing  system  should  not  be  used  as 

substitutes  for  considering  human  factors  principles  in  the  design. 


KEY  REFERENCES 


1.  Bainbridge,  L.  (1979).  Verbal  reports  as  evidence  of  the  process 
operator's  knowledge.  International  Journal  of  Man-Machine  Studies, 
11,  411-436. 

2.  TTammond,  N.  ¥.,  Long,  J.  B.,  4  Clark,  I.  A.  (1978).  Introducing  the 
interactive  computer  at  work;  The  users’  views.  Proceedings  Work- 
shop  on  Computing  Skills  and  Adaptive  Systems,  Liverpool ,12^-144. 

*3.  Hammond,  N.,  Long,  J.,  Clark,  f.  Barnard,  P.,  4  Morton,  J.  (1980). 
Docunenting  human  computer  mismatch  in  interactive  systems.  Ninth 
International  Symposi^  on  Human  Factors  in  Telecommunications. 

4.  Morton,  J.,  Sarnard,  P.  J.,  Haimrjond,  N.  V.,  4  Long,  J.  (1979). 
Interacting  with  the  computer:  A  framework.  Teleinformatics  ‘79, 
201-208. 

5.  Newell,  A.,  4  Simon,  H.  A.  (1972).  Human  problem  solving.  Engle¬ 
wood  Cliffs,  NJ:  Prentice-Hall. 

CROSS  REFERENCES 

6.  Keystroke  model  for  predicting  task  execution  time;  8.  Formal  lan¬ 
guage  as  a  design  tool  for  person-computer  dialogue;  9.  Playback  method¬ 
ology  for  evaluating  person-  computer  dialogue 


♦Principal  reference 


3.  FORMAL  LANGUAGE  AS  A  DESIGN  TOOL  FOR  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

INTERFACE  DESIGN;  SYSTEM  DESCRIPTION;  GUIDELINE  VERIFICATION;  USER  MODEL 
GENERAL  DESCRIPTION 

The  use  of  formal  grammar  as  an  analytic,  predictive  tool  to  aid  man- 
machine  interface  design  is  enhanced  by  defining  the  concepts  involved, 
making  explicit  the  prediction  process,  and  reducing  limitations  of 
predictions.  The  incorporation  of  "cognitive"  information  into  the 
grammar  permits  differential  system  description  for  various  classes  of 
users.  The  prediction  process  includes  assumptions  which  allow  incor¬ 
poration  of  psychological  literature  to  expand  the  limits  of  prediction. 

Figure  3  depicts  the  language  used  to  describe  user  actions.  Two  kinds 
of  actions  are  considered:  information- seeking  actions  (both  cognitive 
and  physical)  and  physical  input  actions  (observable  inputs  to  the 
system).  The  examples  shown  label  the  two  actions  with  the  symbols  "c" 
for  cognitive  or  "i"  for  input. 

An  overview  of  the  prediction  process  is  presented  in  Table  9.  Gram¬ 
matical  models  (Step  1)  do  not  deal  with  experimentally  verifiable 
terms.  Conversion  is  accomplished  by  rewriting  terminal  symbols  to  a 
new  grammar  using  units  of  time  or  error  (Step  2).  For  example:  "<move 
cursor>":  =  tmove  cursor.  This  accomplishes  sentences  with  which  com¬ 
parative  predictions  can  be  made. 

To  make  specific  comparisons,  the  sentences  corresponding  to  the  com¬ 
parisons  to  be  made  are  derived  from  the  grammar.  For  example,  to 
compare  system  use  by  different  user  classes,  the  possible  retrieval 
sources  (e.g.,  book,  human  memory)  are  represented  as  alternations 
("OK's")  in  the  cognitive  rules  in  the  grammar.  In  deriving  the  sen¬ 
tences  corresponding  to  each  class  of  user,  information  seeking  action 
which  is  appropriate  to  that  class  of  user  is  selected.  Thus,  a  naive 
user  might  be  expected  to  use  an  external  source  (e.g.,  book),  while  an 
experienced  user  could  retrieve  this  information  from  his  own  memory. 

To  make  the  prediction  process  explicit  and  powerful,  the  Assumptions  on 
which  the  predictions  are  made  must  also  be  explicit  and  quantifiable 
(Step  4).  These  Assumptions  are  made  from  common  sense  and  the  experi¬ 
mental  findings  of  human  factors  and  psychology.  Assumptions  are  writ¬ 
ten  as  inequalities  or  other  equations,  such  as:  Time  to  retrieve 
information  from  an  external  source  (e.g.,  book)  will  be  greater  than 
time  to  retrieve  from  human  long-term  memory,  i.e.,  >  tj^-j-f/|)* 

For  a  particular  sequence  of  keystrokes,  time  to  type  the  sequence,  for 
users  who  type  at  the  same  typing  speed,  will  be  the  same. 


COGNITIVE  TERMINAL  SYMBOL 


Example: 

<delete  line>::= 


INFORMATION-SEEKING  ACTIONS 


<c-find  out  how  to  delete  line>^::= 
<c- retrieve  from  human  memory > 
<c-retrieve  from  external  source> 

<c-retrieve  from  human  memory>::= 
<c-retrieve  from  long  term  memory> 
<c-retrieve  short  term  memory 
<c-use  muscle  memory>... 

<c-retrieve  from  external  source>::* 
<c-retrieve  from  book> 

<c-ask  someone>... 


cognitive  action 
=  input  action 


PHYSICAL  INPUl 

r  ACTIONS 

<i-delete 

2 

1  i  ne> 

Figure  3.  Elements  of  user  action  language. 


TABLE  9.  ELEMENTS  OF  THE  PREDICTION  PROCESS 


1.  An  action  grammar  describing  both  cognitive  and  input  actions. 

2.  Extensions  to  the  grammar  to  convert  these  actions  to  time  or  errors. 

3.  Sentences  derived  from  the  grammar  for  particular  tasks  and  classes 
of  users. 

4.  A  set  of  Prediction  Assumptions  drawn  from  common  sense.  Psychology 
and/or  Human  Factors. 

5.  Substitutions  from  the  appropriate  assumptions  into  the  sentences  to 
be  compared,  and  solution  according  to  the  normal  rules  of  simple 
algebra. 


Interrelationships  between  them  can  also  be  made  explicit.  For  example, 
if  it  is  assumed  that  (1)  time  to  find  information  in  an  external  source 
is  much  greater  than  time  to  perform  a  typing  action,  and  that  (2)  time 
to  perform  a  typing  action  is  greater  than  time  to  retrieve  information 
from  human  memory,  the  order  between  the  three  quantities  is  obvious. 

Predictions  are  made  (Step  5)  by  algebraically  solving  the  quantified 
terminal  statements  and  prediction  assumptions. 

APPLICATIONS 

Formal  description  of  user  interfaces;  general  analytic  and  predictive 
design  aid. 

Method  of  Application 

For  example,  suppose  predictions  are  to  be  made  about  naive  versus 
skilled  users  whose  typing  speeds  are  equivalent.  Two  sentences  from 
the  granmar  would  be  derived,  one  for  each  of  the  user  classes.  The 
"cognitive"  and  the  "input"  actions  would  be  converted  to  variables 
representing  times.  The  "sentences"  for  the  two  classes  would  differ. 
The  "input  actions"  would  be  the  same,  but  the  information  seeking 
actions  would  differ.  The  naive  user  would  rely  on  the  external  source 
(e.g.,  book);  the  experienced  user  would  rely  on  his/her  human  memory. 
The  Prediction  Assumptions  would  tell  us  that  time  to  retrieve  from  an 
external  source  is  greater  than  time  to  retrieve  from  human  memory. 
Therefore,  a  prediction  would  be  made  that  corresponds  to  our  intuition. 
From  the  prediction  process,  we  would  predict  that  naive  users  would 
take  longer  on  this  task. 

EMPIRICAL  VALIDATION 

Validation  of  the  approach  is  ongoing.  The  validation  methodology 
involves  predictions  and  experimental  results  which  are  being  made  by 
separate  individuals. 
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CONSTRAINTS 


•  Some  of  the  Predictive  Assumptions,  if  not  all,  will  appear  to  be 
too  simple.  Their  importance  to  the  model  is  paramount;  explicitly 
stated  assumptions  allow  analysis  and  resolution  of  crucial  or 
controversial  issues. 

•  “Cognitive"  assumption's  can  be  treated  in  a  variety  of  ways  to  draw 
upon  the  literature.  Broad  familiarity  with  psychological  litera¬ 
ture,  however,  is  required. 

KEY  REFERENCES 

1.  Reisner,  P.  (1982).  Formal  development  toward  using  formal  grammar 
as  a  design  tool.  In  Proceedings  of  Human  Factys  in  Computer 
Systems  (pp.  304-308).  New  York:  Association  i'o'r  Computing  Ma- 
cfTTneryT 

CROSS  REFERENCES 

6.  Keystroke  model  for  predicting  task  execution  time;  7.  A  protocol 

analysis  for  documenting  user  problems  with  interactive  systems 


9.  PLAYBACK  METHODOLOGY  FOR  EVALUATING  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

SYSTEM  EVALUATION;  USER  PERFORMANCE;  VALIDATION 

GENERAL  DESCRIPTION 

Playback  is  a  general  purpose  data  collection  program  to  evaluate  user 
performance  with  person-computer  interfaces.  Measurements  of  ease-of- 
learning  may  include: 

•  Time  to  complete  a  training  program 

•  Time  to  achieve  a  performance  criterion 

•  Observed  difficulty  in  learning  a  product 

•  User  comments,  suggestions,  and  preferences. 

Measurements  of  ease-of-use  after  initial  learning  may  include: 

•  Time  to  perform  selected  tasks 

•  Success  in  task  completion 

•  Frequency  of  use  of  commands  or  language  features 
0  Time  spent  locating  information  in  documentation 
0  User  comments,  suggestions,  and  preferences. 

Other  measures  of  user  problems  could  include: 

0  Inability  to  find  information  in  documentation 
0  Frequency  that  each  error  message  is  encountered 
0  Frequency  of  use  of  on-line  help 

0  Use  of  special  assistance  (simulated  product  support). 
Apparatus: 

Playback  provides  a  method  for  unobtrusively  measuring  these  variables 
and  storing  the  data  for  post-hoc  analysis.  Figure  4  diagrams  the 
playback  system  configuration.  The  interface  logic  box  provides  inter¬ 
ception  of  keystroke-level  user  behavior  for  time-stamp  and  storage  in 
the  lab  computer.  Time  is  recorded  to  msec  tolerances. 


Figure  4.  Schematic  diagram  of  playback  system. 
(Source:  Neal. 4  Simons,  1983) 


The  experimenter  station  (Figure  5)  provides  remote  observation  of  user 
behaviors,  on-line  interaction  with  the  software  and  the  use  of  documen¬ 
tation.  The  experimenter  records  objective  observations  (codes  and 
narrative  comments)  to  supplement  the  keystroke-level  data  in  the  play¬ 
back  analysis. 
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Figure  5.  Experimenter  station  and  sample  of  objective  observations 
(Source:  Neal  4  Simons,  1983) 
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Analysis: 


Playback  analysis  can  be  performed  at  various  points  of  the  data  col¬ 
lection:  after  all  of  the  required  user  sessions  or  after  selected 
sessions.  The  playback  software  permits  analysis  of  user  behaviors  by 
"playing  back"  sequences  of  user  keystrokes  in  any  of  four  pacing  units 
selectable  by  the  experimenter. 

•  Next  character  or  function 

•  All  characters  up  to  and  including  the  next  interrupt 

•  All  characters  and  functions  up  to  and  including  the  next 
interrupt 

•  All  characters  up  to  and  including  the  next  function  with  the 
same  time  intervals  as  when  originally  keyed  by  the  user. 

Figure  6  is  a  sample  page  of  a  playback  analysis. 


Subject  12  Session  1  Condition  4 

0:20:30  CLEAR 

0:20:55  A  =  (22/7)  *  R**2 

0:21:20  ENTER  Interval:  50  sec. 

■ . OBSERVATIONS . 

0:20:38  P19K 

0:22:02  RTK  Searching  for  topic  in  Table  of  Contents 


PFl:  Next  keystroke 

PF2:  Next  function 

PF3:  Next  interrupt 

PF4:  Real  time 

PF6:  Set  time 

< — :  Backup  CLEAR: 

Abort 

0:21:20  E5 

Syntax  error  because 

referring  to  wrong  page 

in 

Programmer's  Guide 

Figure  6.  Example  of  a  playback  screen.  (Source:  Neal  &  Simons,  1983) 


Pacing  units  can  be  changed  at  any  point  in  the  analysis  and  sequences 
of  interest  can  be  repeated  at  will.  During  the  playback  analysis,  the 
experimenter  can  further  annotate  user  behaviors,  as  during  data  collec¬ 
tion. 

The  playback  software  computes  and  records  the  following  objective 
statistics  for  each  session: 

•  Time  from  session  beginning  until  user’s  first  keystroke 
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•  Time  from  session  beginning  until  user's  last  keystroke 

•  Cumulative  time  in  a  "Help"  condition 

•  Frequency  of  use  of  each  function  key 

•  Number  of  requests  for  help 

•  Frequency  of  use  of  selected  commands. 

APPLICATIONS 

Dialogue  simulation  experiments;  design  of  new  person-computer  dialogue; 
troubleshooting  problem  dialogue. 

CONSTRAINTS 

•  Validation  of  playback  methodology  has  not  been  published  in  the 
literature  which  has  been  reviewed. 

•  Playback  provides  analyses  of  terminal  protocol  and  observed  incom¬ 
patibilities  only;  does  not  provide  systematized: 

-  Collection  of  verbal  protocols 

-  Modelling  of  cognitive  incompatibilities 

-  Generalization  of  models  and  hypotheses. 

-  Analysis  of  results.  Including: 

•  The  workplace  environment:  Comfort,  lighting  and  noise 

•  The  terminal  keyboard:  Keying  errors,  confusions  and  delays 

•  The  terminal  display:  Legibility  and  formatting 

•  General  system  operating  characteristics:  Control  of  the  ter¬ 
minal,  system  response  time,  allocation  of  space 

•  The  interactive  language:  Lexical,  syntactic  and  semantic 

•  The  interactive  language:  Interpretation  of  system  responses 

•  Task  organization  influenced  by  the  system:  Imposed  goal 
structures 

•  Task  organization  independent  of  the  system:  Conditions  of 
the  study 

•  Amount  of  data  obtained  may  be  overwhelming. 

KEY  REFERENCES 

*1.  Neal,  A.  S.,  i  Simons,  R.  M.  (1983,  December  12-15).  Playback:  A 
method  of  evaluating  the  usability  of  software  and  its  documenta¬ 
tion.  In  Janda,  A.  (Ed.)  Proceedings  of  Cm-83  Human  Factors  in 
Computing  Systems  (pp.  78-82).  hlew  York:  Association  for  (iomputing 
Machinery. 

2.  Hammond,  N.,  Long,  J.,  Clark,  I.  Barnard,  P.,  &  Morton,  J.  (1980). 
Documenting  human-computer  mismatch  in  interactive  systems.  In 
Ninth  International  Symposium  on  Human  Factors  in  Telecommunica¬ 
tions. 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue  design;  6.  Keystroke  model  for 
predicting  task  execution  time;  7.  A  protocol  analysis  for  documenting 
user  problems  with  interactive  systems;  8.  Formal  language  as  a  design 
tool  for  person-computer  dialogue 


♦Principal  reference 
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10.  INTERFACE  DESIGN  PRINCIPLES  DERIVED  FROM  HUMAN  ERROR  ANALYSES 


KEY  TERMS 

DESIGN  GUIDELINES;  COGNITIVE  ENGINEERING;  HUMAN  ERROR;  MODE  ERRORS; 
DESCRIPtlON  E^RRORS;  (!:APfURE!  ERRORS;  ACTIVA•fId^l  gl^l^^RS 

GENERAL  DESCRIPTION 

Analyses  of  the  frequency,  cause,  and  consequence  of  user  errors  pro¬ 
vide  information  for  designing  more  effective  user-machine  interfaces. 
Error  analysis  cannot  address  all  classes  of  problems  and  should  be 
supplemented  with  analyses  of  the  user's  mental  model  of  the  system  and 
the  human  information  processing  capabilities  of  the  user. 

A  general  analysis  of  human  errors,  both  in  everyday  events  and  in  usage 
of  computer  systems,  yielded  the  taxonomy  of  human  errors  given  in  Table 
10.  For  selected  error  types.  Table  11  presents  the  general  cause  of 
the  error,  an  example,  and  preventative/corrective  actions.  The  design 
rules  follow  the  general  principles  of  providing  feedback  to  users,  use 
of  distinctive  command  sequences,  protection  against  inadvertent  activa¬ 
tion  of  critical  or  fatal  actions,  and  consistency. 

APPLICATIONS 

Design  of  man-machine  interfaces;  design  of  person-computer  dialogue; 
design  and  layout  of  controls;  design  and  layout  of  displays. 

CONSTRAINTS 

0  These  data  form  only  the  early  stages  of  a  "cognitive  engineering" 
discipline;  further  research  will  provide  additional  design  princi¬ 
ples  based  on  cognitive  theory. 

0  These  data  summarize  analyses  of  human  performance  and  errors; 
incorporation  of  human  information  processing  analyses  and  user's 
mental  models  will  be  needed  for  a  well-rounded  discipline. 

0  Utilization  of  these  data  depend  upon  highly  detailed  knowledge  of 
the  user  populations,  man-machine  interface,  and  error  analyses. 

0  This  taxonomy  of  errors  is  only  one  of  many  which  are  available. 

KEY  REFERENCES 

1.  McFarland,  R.  (1973).  Application  of  human  factors  engineering  to 
safety  engineering  problems.  In  J.  Widener  (Ed.),  Selected  readings 
in  safety.  Macon,  GA:  Academy  Press. 
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TABLE  10.  CLASSIFICATION  OF  ERRORS  (Source:  Norman,  1983) 


Slips  in  the  Formation  of  Intention 

•  Mode  errors:  erroneous  classification  of  the  situation 

•  Description  errors:  ambiguous  or  incomplete  specification  of  the 
intention 

Slips  Resulting  from  Faulty  Activation  of  Schemas 

•  Unintentional  activation:  when  schemas  not  part  of  a  current  action 
sequence  become  activated  for  extraneous  reasons,  then  become  trig¬ 
gered  and  lead  to  slips 

•  Capture  errors:  when  a  sequence  being  performed  is  similar  to 
another  more  frequent  or  better  learned  sequence,  the  latter  may 
capture  control 

•  Data-driven  activation:  external  events  cause  activation  of  schemas 

•  Associative  activation:  currently  active  schemas  activate  others 
with  which  they  are  associated 

•  Loss  of  activation:  when  schemas  that  have  been  activated  lose 
activation,  thereby  losing  effectiveness  to  control  behavior 

•  Forgetting  an  intention  (but  continuing  with  the  action  sequence) 

•  Misordering  the  components  of  an  action  sequence,  including  skipping 
steps  and  repeating  steps 

Slips  Resulting  from  Faulty  Triggering  of  Schemas 

•  False  triggering:  a  properly  activated  schema  is  triggered  at  an 
inappropriate  time 

•  Spoonerisms:  reversal  of  event  components 

•  Blends:  combinations  of  components  from  two  competing  schemas 

•  Thoughts  leading  to  actions:  triggering  of  schemas  meant  only  to  be 
thought,  not  to  govern  action 

f  Premature  triggering 

•  Failure  in  triggering:  when  an  active  schema  never  gets  invoked 
because: 

Action  was  preempted  by  competing  schemas; 

There  was  insufficient  activation,  either  as  a  result  of  forget¬ 
ting  or  because  the  initial  level  was  too  low; 

There  was  a  failure  of  the  trigger  condition  to  match,  either 
because  the  triggering  conditions  were  badly  speciHed  or  the 
match  between  occurring  conditions  and  the  required  conditions 
was  never  sufficiently  close. 


TABLE  11.  REDUCTIOfj  OE  SEEECTED  ERROR  TYPES  (Source;  Norman,  19«3) 


ERROR  nPt 

CAUSE 

EXAMPLE 

PREYENTION/CORRECTION 

Hode  Errors 

Lack  of  clear  feedback 

Computer  text  editor 

Provide  more  feedback 

as  to  current  state 

0  issuing  commands 
in  text  mode 

Q  entering  text  In 
command  mode 

Pushing  buttons  on 
complex  digital 
watches 

Entering  data  on  auto¬ 
pilots  of  commercial 
aircraft 

and  indication  of  cur¬ 
rent  system  state 

Description 

When  different  actions 

Multiple  use  keys  in 

Arrange  Instrunents  and 

Errors 

have  similar  de- 

computer  text  edl- 

controls  In  functional 

scriptlons,  either 

tors  (e.g.,  “d," 

patterns 

In  specification  of 

“sh1ft-d,“  "control- 

Shape  code  controls  for 

the  action  or  in  the 

d") 

distinctiveness 

class  of  argument 

Throwing  switches  or 

Make  actions  with  critl- 

Control  panels  without 

operations  of  con- 

cal  implications  dif- 

adequate  distinc* 

trol  s 

ficult  to  perform 

tions  among  controls 

0  altimeters 

Organize  computer 

for  quick  glance  or 

0  radio  frequencies 

screens  and  menus 

peripheral  vision 

0  transponder  codes 

functional  ly 

inspection 

0  nuclear  power 
plant  control 
rooms 

Derivation  of  unknown 
connand  structure 
by  analogy  with 
similar  (known  to 
user)  connand 

Design  coimand  language 
or  menu  headings  to  be 
distinct  in  appearance 
and  required  actions 
Consistency  in  command 
sequence  formation 

Capture 

Overlap  In  sequence 

Berkley  release  of 

Minimize  overlap  by 

Errors 

required  for  per- 

UNIX  operating 

using  vastly  different 

fomiance  of  two  dif- 

system  write  file 

commands 

ferent  actions  when 

option: 

Determine  critical 

one  Is  more  familiar 

:W  ■  write  file 

points  where  errors 

than  the  other.  Fa- 

:Q  •  quit  editor 

occur  and  design  sys- 

miliar  act  takes 

:WQ  ■  write,  then 

tern  to  flag  or  other- 

precedence  over  un- 

quit 

wise  bring  to  opera- 

familiar  act 

If  ;WQ  Is  most  fre¬ 
quently  done  and 
Intention  Is  to  write 
and  continue  editing 
(:k),  one  may  err 
and  enter  :WQ 

tor's  attention 

Activation 

Inappropriate  actions 

Inappropriate  action 

Provide  memory  aids 

Errors 

are  performed 

sequence  activation 

Design  system  for  toler- 

Appropriate  actions 
are  not  performed 

resulting  from 
relation  to  desired 
sequence 

Failure  to  perform 
action  from  memory 
failure 

ance  of  errors 

2.  Meister,  D.,  &  Rabideau,  G.  F.  (1965).  Human  factors  evaluation  in 
system  development.  New  York,  NY:  Wiley  Publishers. 

*3.  iJdrm'an,  6.  A.  (1983).  Steps  toward  a  cognitive  engineering:  De¬ 
signing  rules  based  on  analyses  of  human  error.  In  Janda  A.  (Ed.) 
Proceedings  of  CHI-83  Human  Factors  in  Computing  Systems:  (pp. 
3/^-382) .  t^e'w  York:  Association  for  Computing  Machinery. 

4.  Rasmussen.  J.  (1978,  November).  Notes  on  human  error  analysis  and 
prediction.  Roskilde,  Denmark:  Riso  National  Laboratory. 

5.  ft'igby,  L.  (1970).  The  nature  of  human  error.  Annual  Technical 
Conference  Transactions  of  the  ASQC.  Milwaukee,  W:  American 
Society  for  Quality  ControTT 

6.  Singleton,  W.  T.  (1977).  Techniques  for  determining  the  causes  of 
errors.  Applied  Ergonomics,  2(3),  126-131. 

7.  Swain,  A.,  &  Guttman,  H.  (1980).  Handbook  of  human  reliability 
analysis  with  emphasis  on  nuclear  power  plant  applications,  ^bu- 
querque,  NM:  Sandia  Laooratories. 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue  design;  20.  Error  recovery  in 

person-computer  dialogue 


♦Principal  reference 


11.  TAXONOMY  OF  COMPUTER-USER  CHARACTERISTICS 


KEY  TERMS 

USER  GROUPS;  USER  REQUIREMENTS;  FRONT-END  ANALYSIS 

GENERAL  DESCRIPTION 

A  frequently  emphasized  facet  of  interactive  system  design  is  knowledge 
of  the  user  population.  Precise  description  of  the  important  variables, 
however,  is  left  open  to  interpretation.  The  resulting  actions  are  not 
often  in  accordance  with  what  will  be  truly  useful  (Ref.  1). 

"Know  thy  user"  must  go  beyond  mere  identification  and  stereotyping  of 
the  user  population,  especially  when  these  data  are  obtained  through 
indirect  means  or  logical  conjecture.  Without  direct  contact  between 
designer  and  the  user  groups,  underestimation  of  the  diversity  and 
capabilities  of  the  user  groups  can  occur.  Interaction  between  design¬ 
ers  and  the  users  can  provide  invaluable  insights  into  the  differences 
between  designers  of  systems  and  users  of  systems. 

Table  12  lists  10  dimensions  of  users  which  should  be  considered  by 
system  designers.  Although  these  characteristics  cannot  be  linked 
directly  to  specific  design  guidelines,  these  data  provide  background 
information  for  design  of  systems  compatible  with  the  users. 

APPLICATIONS 

Front-end  analysis  of  user  characteristics;  selection  of  dialogue  type. 

CONSTRAINTS 

•  Application  of  these  data  is  limited  by  the  depth/breadth  and  vali¬ 
dity  of  the  data  collection. 

•  Variability  of  user  populations  on  these  dimensions  may  be  extremely 
high  in  some  application  areas. 

•  Few  user  characteristics  have  been  proven  to  be  reliable  predictors 
of  performance  with  computers. 

KEY  REFERENCES 

1.  Gould,  J,  0,,  &  Lewis,  C.  (1983).  Designing  for  useability  -  Key 
principles  and  what  designers  think.  In  Janda,  A.  (Ed.)  Proceedings 
of  CHI  '83  Human  Factors  in  Computing  Systems  (pp.  50-53)T  !Tew 
York,  MY;  Association  for  Computing  Machinery. 

*2.  Nickerson,  R.  S.,  i  Pew,  R.  W.  (1977).  Person-computer  interaction. 
In  Nickerson,  R.  S.,  Adams,  M.  J.,  Pew,  R.  W.,  Swets,  J.  A.,  Fidell, 
S.  A.,  Feeher,  C.  E.,  Yntema,  D.  B.,  &  Green,  D.  M.,  The  C3  system 
user.  Volume  I  (Report  Number  3459).  Cambridge,  MA:  Bolt,  Beranek 
and  Newman. 


♦Principal  reference 
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TABLE  12.  TAXONOMY  OF  INTERACTIVE  SYSTEM  USERS:  SELECTED  DIMENSIONS 
(Source:  Nickerson  &  Pew,  1977) 


•  Knowledge  or  expertise  as  a  computer  programmer,  systems  analyst, 
computer  operator,  or  other  computer- re la ted  specialist. 

•  Knowledge  concerning  the  specifics  required  for  carrying  out  the  job. 
What  can  be  assumed  concerning  the  user's  understanding  of  how  a 
particular  application  is  to  be  can  ied  out? 

•  The  extent  to  which  user's  job  or  activity  will  focus  on  interactive 
terminal  usage.  Will  he  be  using  a  tenninal  on  a  dedicated  or  casual 
basis?  Will  the  terminal  serve  as  an  information  source  or  as  the 
basis  for  regular  work  performance? 

•  Level  of  decision-making  authority  and  responsibility. 

•  Educational  background. 

•  Availability  of  special  skills  or  aptitudes  such  as  clerical  skills, 
managerial  skills,  mathematical  skills. 

•  Expected  duration  of  stay  in  particular  job;  employee  turnover. 

•  Sources  of  job-related  motivation.  Is  the  user  intrinsically  moti¬ 
vated  or  must  the  interactive  tasks  be  designed  to  promote  motiva¬ 
tion. 

•  Extent  to  which  terminal  usage  will  be  an  option  versus  a  job  re¬ 
quirement. 

•  Attitudes  toward  computer  technology  and  its  introduction  in  the  work 
setting. 


CROSS  REFERENCES 


1.  Steps  in  person-computer  dialogue  design;  3.  Comparison  of  approaches 
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12.  DESIGNING  FOR  THE  CASUAL  OR  INFREQUENT  COMPUTER  USER 


KEY  TERMS 

NAIVE  USER;  QUERY  LANGUAGE  REQUIREMENTS;  DATABASE  QUERY  SYSTEMS 
GENERAL  DESCRIPTION 

Design  of  data  retrieval  systems  and  dialogue  for  casual,  novice,  or 
infrequent  users  differs  greatly  from  systems  specifically  intended  for 
experienced  or  professional  users.  Designers  must  consider  the  con¬ 
sequences  of  infrequent  use,  including  poor  retention  of  system  and 
training  details.  Productive  design  efforts  will  emphasize  principles 
rather  than  details  for  effective  user  training.  Error  detection  and 
correction  functions  can  be  guided  by  the  system  to  combat  the  typical 
error-prone  nature  of  an  infrequent  user’s  query.  Casual  users  expect 
(and  need,  if  maximum  efficiency  is  to  be  attained)  a  system  that  feels 
"natural,"  i.e.,  corresponds  with  their  "non-computer"  dialogue  percep¬ 
tions.  These  include  courteous,  rational,  and  informative  interactive 
dialogue  which  can  also  deal  with  the  foibles  of  human  dialogue.  Human 
dialogue  foibles  include  tolerance  for  imprecise  logic  or  specifica¬ 
tions,  implicit  or  contextual  references  to  previous  queries,  and 
requests  for  additional  information.  Failure  to  consider  specifically 
the  abilities  and  needs  of  the  casual  user  can  result  in  poor  user 
performance  due  to  extended  time  in  training,  increased  error  frequency 
and  error  recovery  time,  high  amounts  of  inadvertently  retrieved  data, 
or  extensive  amounts  of  time  negotiating  the  dialogue.  Other  results  of 
inadequate  dialogue  design  for  the  casual  user  can  be  reluctance  or 
refusal  to  use  the  system.  Table  13  presents  selected  guidelines  for 
design  of  systems  for  casual  users. 

APPLICATIONS 

Query  language  development;  data  base  systems;  management  information 
systems. 

CONSTRAINTS 

e  Requirements  of  casual  users  have  not  been  subjected  to  extensive 
study, 

•  Most  of  the  guidelines  are  not  based  on  experimental  studies;  others 
are  based  loosely  on  empirical  findings. 

•  Design  must  include  numerous  trade-offs  if  multiple  user  groups  are 
anticipated  and  multiple  dialogue  types  are  not  feasible. 

KEY  REFERENCES 

1.  Cuff,  R.  (1980).  On  casual  users.  International  Journal  of  Man- 
Machine  Studies,  12 ,  163-187. 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue  design 
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TABLE  13.  SELECTED  GUIDELINES  FOR  DESIGNING  PERSON- 
COMPUTER  DIALOGUE  FOR  THE  CASUAL  USER 


DESIGN  FOR  A  FORGETFUL  USER 

Train  Users  in  Principles  -  Not  Details 

•  Emphasize  conceptualization  of  system  as  a  whole 

•  Provide  concise  groundings  in  the  principles  of  the  interface 

•  Do  not  rely  on  existing  skills  in  users 

Provide  Explicit,  Constrained  Choices  for  User  Inputs: 

•  Use  menu  selection  or  prompting  messages 

•  Make  available  choices  apparent 

Use  "Natural  Language"  Interface  for  Communication  on  User's  Terms. 
Provide  System  Guidance  to: 

•  Restrict  queries  within  system  competence 

•  Continue  progression  of  a  dialogue 

•  Supplement  information  presented  in  display,  preferably  on-line 
MINIMIZE  SYSTEM-PROVIDED  OPPORTUNITY  FOR  USER  ERRORS 

Limit  Number  of  Things  User  Must  Consider  at  One  Time 

•  Menu  selection:  10  or  less  items;  selection  by  consistent  method 

•  Prompting  systems:  Restrict  responses  to  well-defined  range  of 
values;  utilize  "query- in-depth"  for  system-initiated  remediation 
of  inappropriate  responses 

Include  Corrective  Features  in  System-Detected  Errors 

•  Attempt  prediction  of  user's  intended  entry 

•  Initiate  sub-dialogues  for  clarification 

•  Describe  corrective  actions  in  error  messages 

Word  Error  Message  for  User  Acceptance 

•  Use  humble  wording  to  retain  user's  goodwill 

•  Provide  at  least  two  alternately  phrased  messages 

PROVIDE  FEEDBACK  FOR  USER  GUIDANCE  AND  REASSURANCE 

Include  Unambiguous  System  Responses  for  All  User  Entries  For: 

•  Reinforcement  of  correct  responses 

•  Error  detection 

•  User  identification  of  system  actions 

Use  Dialogue  Which  Is  Easily  Understandable 

•  Avoid  computer  jargon 

•  Avoid  unusual  terms  or  abbreviations 

Maintain  a  Natural  Flow  of  Dialogue 

•  "Natural"  ordering  of  questions  and  inputs 


-55- 


TABLE  13.  SELECTED  GUIDELINES  FDR  DESIGNING  PERSON- 

CDMPUTER  DIALOGUE  FOR  THE  CASUAL  USER  (Cont.) 


MATCH  DATABASE  QUERY  SYSTEM  TO  INFREQUENT  USER'S  ABILITIES 

Reduce  Data  Structure,  Content,  or  Semantics  Knowledge  Requirements 

•  Data  should  be  requested  by  descriptive  terms 

•  System  should  guide  user  through  valid  choices 

•  Requests  by  field  (attribute)  or  record  (relational)  names  should 
be  minimal 

•  Names  and  descriptive  phrases  should  be  displayable  upon  user 
request 

•  When  multiple  logic  paths  occur,  choices  should  be  explained  In 
user-oriented  terms 

Design  for  Deviations  In  Query  Precision 

•  Anticipate  vague,  exploratory  queries  before  precise  questions 

•  Guard  against  excessive  output  from  broad  or  erroneous  requests, 
even  If  query  appears  legitimate 

•  If  specific  attributes  of  an  entity  are  requested,  consider  sup¬ 
plying  others  to  facilitate  query  formulation  and  data  retrieval 

Match  Dialogue  Language  to  the  Needs  and  Abilities  of  Users 

•  Reduced  language  formality  can  facilitate  casual  users 

•  System  aided  syntax  error  detection/correction  Is  desirable 

•  Implicit  logic  specification  Is  less  error-prone  than  explicit  use 
of  logical  connectives  and  quantifiers 

•  Plan  for  logical  errors  In  syntactically  correct  queries  If 
explicit  logic  Is  required 


13.  SYSTEM  RESPONSE  TIME  AND  THE  EFFECT 
ON  USER  PERFORMANCE  AND  SATISFACTION 


KEY  TERMS 

SYSTEM  RESPONSE  INITIATION  TIME;  DISPLAY  WRITING  TIME;  ARTIFICIAL  LOCK- 

OUTT  'SYSW  TIME'  VAmTigif - 

GENERAL  DESCRIPTION 

Degradation  in  user  performance  is  a  non-linear  function  of  system 
response  time  (SRT)  when  certain  criteria  are  violated.  Four  major  SRT 
categories  and  their  characteristics  have  been  identified  {Refs.  2,  12, 
13): 

1.  Greater  than  15  sec. 

e  Too  slow  for  conversational  dialogue 

•  Free  user  from  captivity  of  waiting  for  system 

•  Allow  user  to  get  answer  at  own  convenience 

•  Message  of  expected  delay  is  desirable 

2.  Five  to  15  sec. 

•  Too  slow  for  interactive  conversation 

•  Frustrates  users  in  problem  solving  and  data  entry  activities 
e  Allows  unproductive  behaviors  or  shifts  to  other  task 

3.  Two  sec. 

•  Too  slow  for  users  at  high  concentration  level 

4.  Almost  instantaneous. 

Variation  in  SRT  can  be  as  detrimental  as  long  SRT's  (Ref.  10).  General 
recommendations  are: 


SRT  Maximum  Variability 

0-2  second  +5J 

5  second  +10% 

>5  second  ^15% 

Acceptable  SRTs  are  dependent  upon  a  user's  expectations  of  system 

performance  and  perceived  system  activities  to  perform  the  task.  Table 
14  lists  recommended  SRTs  and  maximum  variability  for  specific  user 
activities/tasks.  Reduction  of  SRT  below  the  user's  preparation  time 
provides  little  or  no  performance  advantage  (Refs.  4  &  9). 

APPLICATIONS 

Interactive  computer  systems  in  which  "conversational"  dialogue,  rather 
than  on-line  batch  dialogue,  is  the  intended  mode.  Situations  where 
human  performance  and  satisfaction  are  paramount  to  a  system's  success¬ 
ful  mission  or  use. 
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RECOMMENDED  SYSTEM  RESPONSE  TIMES  (Adapted  from:  Gallaway,  1981 


TABLE  14.  RECOMMENDED  SYSTEM  RESPONSE  TIMES  (Source:  Gall  away,  1981  (Cont.) 


CONSTRAINTS 


•  System  response  time  definition  (Ref.  10): 


■System  Response  Time  (SRT) 


System 

Response _ 

"initiation 
Time  (SRIT) 


Display 
Wri ti ng 


Arti  ficial 
lockout 


Completion 
of  user 
inquiry 


Start  of 
computer 
response 


Completion 
of  computer 
response 


User  allowed 
to  start 
next  inquiry 


•  Artificial  lockout  may  improve  complex  problem-solving  performance 
but  reduces  user  satisfaction  (Refs.  1,  6,  4  12). 

•  Effects  due  to  display  writing  time  have  not  been  adequately  re¬ 
searched. 

KEY  REFERENCES 

1.  Boehm,  B.  W.,  Seven,  M.  J.,  S  Watson,  R.  A.  (1971).  Interactive 
problem-solving:  An  experimental  study  of  "lockout"  effects.  AFIPS 
Conference  Proceedings,  38,  205-210. 

2.  Carbonnell,  J.  rt.,  £1kin77  J.  I.»  &  Nickerson,  R.  S.  (1968).  On  the 
psychological  importance  of  time  in  a  time-sharing  system.  Human 
Factors,  10,  135-142. 

3.  La^on,  K."TT.  (1976).  A  task- tool  analysis  of  manager-computer 
interaction.  A  paper  presented  at  NAtO  Advanced  ^tudy  Institute  on 
Man-Computer  Interaction,  Mati,  Greece.  (Reprinted  by  Department  of 
Human  Sciences,  University  of  Technology,  Loughborough,  Leicester¬ 
shire,  England.) 

4.  Franklin,  J.,  &  Dean,  E.  (1974,  May- June).  Some  expected  and  not  so 
expected  reactions  to  a  computer-aided  design  with  interactive 
graphics  (CANDIG)  system.  SID  Journal,  5-6,  8,  11-13. 

*5.  Gallaway,  G.  R.  (1981).  Response  t^mes  to  user  activities  in  inter¬ 
active  man/machine  computer  systems.  In  Proceedings  of  the  25th 
Annual  Meeting  of  the  Human  Factors  Society  (pp.  7'54-y^8).  Santa 
Monica,  C'A:  The  Muman  F'actors  Society. 

6.  Gold,  M.  M.  (1967).  A  methodology  for  evaluating  time-shared  compu¬ 
ter  system  usage.  Unpublished  doctoral  dissertation,  Massachusetts 
institute  of  Technology,  Cambridge,  MA. 

7.  Miller,  R.  B.  (1968).  Response  time  in  man-computer  conversational 
transactions.  AFIPS  Conference  Proceedings,  33(pt.  1),  267-277. 

8.  Morefield,  M.  A.,  Uiesen,  R.  A.,  Grossberg,  M.,  &  Yntema,  D.  B. 
(1969).  Initial  experiments  on  the  effects  of  system  delay  on 
on-line  problem  soiying  (TN-196^-^).  Cambridge,  Ma:  Massachusetts 
Institute  of  Technology,  Lincoln  Laboratories. 


♦Principal  reference 
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9.  Newman,  M.  M.  (1969).  Interactive  graphical  response  and  Its 
effects  on  display  system  performance.  In  Proceedings  of  the  In¬ 
ternational  Symposium  on  Man-Machine  Systems,  4  (IEEE  Conference 
Record  fJo.  69d58-MM§).  fJew  york','  >1Y:  Institute  of  Electrical  and 
Electronics  Engineers,  Inc. 

10.  Ramsey,  H.  R.,  i  Atwood,  M.  E.  (1979).  Human  factors  In  computer 
systems:  A  review  of  the  literature  (Technical  Report 
:>a1-79-111-deN) .  Englewood,  CO:  Science  Applications,  Inc.  (NT IS 
AD  A075  679) 

11.  Seven,  M.  J.,  Boehm,  B.  W.,  S  Watson,  R.  A.  (1971).  A  study  of  user 
behavior  In  problem-solving  with  an  Interactive  computer  (R-^i3- 
NASA) .  Santa  Monica,  CA:  Rand  Corp. 

12.  Simon,  H.  A.  (1966).  Reflections  on  time  sharing  from  a  user's 
point  of  view.  Science  Research  Review,  43-51. 

13.  Williams,  0.  0.  TToTSTI  The  effects  of  computer  subsystem  response 
time  and  response  time  variance  on  operator  performance  In  an  Inter¬ 
active  ccOTpute'r  system,  ^aper  presented  at  meeting  of  the  American 
Psychological  Association,  Chicago,  IL. 

CROSS  REFERENCES 

1.  Steps  In  design  of  person-computer  dialogue;  36.  Guidelines  for  use 
of  non-critical  auditory  signals 
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14.  INFORMATION  BANDWIDTH  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

DIALOGUE  POWER;  EASE  OF  USE;  MULTIPLE  PURPOSE  DIALOGUE 
GENERAL  DESCRIPTION 

In  designing  dialogues  for  general  usage,  a  trade-off  must  be  made 
between  ease  of  use  and  information  bandwidth  based  on  the  characteris¬ 
tics  of  the  user. 

Information  bandwidth,  the  quantity  of  information  communicated,  or 
decisions  made  in  a  given  time,  using  a  dialogue,  is  highly  dependent  on 
the  efficiency  of  information  encoding.  Although  some  user  types  (pro¬ 
fessionals  and  managers)  may  require  a  high  bandwidth  of  information, 
system  acceptability  may  be  low  if  the  system  is  difficult  to  use. 

Highly  desirable  dialogues  (large  quantity  of  information  and  easy  to 
use)  appear  in  the  upper  left  quadrant  of  Figure  7.  The  lower  right 
quadrant  includes  dialogues  to  be  avoided  due  to  narrow  application  and 
dependence  on  highly  proficient  users. 

The  rate  of  change  for  variable  data  displays  in  the  screen  design  must 
be  limited,  however,  to  maintain  consistency  with  human  information 
processing  limitations.  Suggested  limitations  include  no  more  than  a  1 
Hz  update  of  the  most  important  dynamic  information,  and  a  limit  of  the 
proportion  of  dynamic  data  being  displayed  of  40t  of  the  displayed 
parametric  data  (Ref.  1). 

For  higher  information  bandwidth  displays,  it  is  imperative  to  consider 
related  variables  such  as  coding,  formatting  and  structuring  of  the  data 
display. 

APPLICATION 

Selection  of  dialogue  mode  based  on  characteristics  of  the  users'  abili¬ 
ties/needs;  multiple-application  (general  purpose)  dialogue  design. 

CONSTRAINTS 

•  Information  bandwidth  is  not  necessarily  proportional  to  physical 
channel  bandwidth. 

•  For  development  of  the  figure,  information  bandwidth  was  subjective 
(estimate  of  number  of  basic  assembler  code  lines  equivalent  to  five 
min  of  dialogue). 

f  Efficiency  of  the  dialogue  does  not  predict  the  usefulness  of  dia¬ 
logue. 

•  Major  differences  exist  between  easy-difficult  and  high-low  informa- 
tfon  bandwidth  dialogues. 

•  High  flexibility  or  power  (potentially  desirable  characteristic) 
may  result  in  greater  time  to  become  proficient. 


X  Symbolic  uses 


Figure  7.  Dialogue  power  and  ease-of-use.  (Source;  Martin,  1973) 


t  "Undesirable"  dialogues  may  hold  utilitarian  value  for  specific  or 
narrow  applications. 

•  Easy  to  use/high  information  bandwidth  dialogues  can  substantially 
increase  the  hardware,  communications  and  programming  complexity. 

KEY  REFERENCES 

1.  Hendricks,  D.,  Kilduff,  P.,  Brooks,  P.,  Marshak,  R.,  &  Doyle,  B. 

( 1982 ) .  Human  engineering  guidelines  for  management  information 
systems.  Alexandria,  VA:  U.S.  Army  Materiel  Development  and  Readi¬ 
ness  Command. 

*2.  Martin.  J.  (1973).  Design  of  man-computer  dialogues.  Englewood 
Cliffs.  NJ:  Prentice-Hall. 

CROSS  REFERENCES 

25.  Presenting  numeric  data  in  person-computer  dialogue;  26.  Presenting 
text  data  in  person-computer  dialogue;  27.  Presenting  tabular  data  in 
person-computer  dialogue;  28.  Graphics  in  person-computer  dialogue;  29. 
Information  coding  in  person-computer  dialogue;  32.  Screen  layout  and 
structuring  of  person-computer  dialogue  displays 


♦Principal  reference 
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15.  DESIGN  RECOMMENDATIONS  FOR  QUERY  LANGUAGES 


KEY  TERMS 

QUANTIFIERS;  MIXED  INITIATIVE  DIALOGUE;  DATA  ORGANIZATION;  ABBREVIA- 
TIONS;  nTHTral  LA>J6llA6g;  I^6RMal  qJ^rV  LAdgUAGE;  TMt^dl^MAL  QUiffY 'L'AMGUAGE 


GENERAL  DESCRIPTION 

Guidelines  for  the  design  of  query  languages  have  been  derived  from  two 
types  of  research:  (1)  studies  of  the  query  behaviors  of  computer-naive 
users  and  attempts  to  facilitate  query  formulation  in  natural  languages, 
and  (2)  usability  studies  of  specific  languages.  Although  relatively 
few  studies  compare  across  languages  or  across  the  entire  process, 
errors  emerging  from  these  studies  provide  considerable  insight  into  the 
kinds  of  logical  constructions  and  query  language  features  that  repre¬ 
sent  difficulties  for  users. 

Table  15  displays  some  known  problem  areas  in  the  use  of  query  lan¬ 
guages.  For  each  problem  area,  comments  and  references  are  provided.  A 
collection  of  recommendations  and  guidelines,  distilled  from  the  litera¬ 
ture  (Ref.  1),  are  presented  in  Table  16.  The  recommendations  speci¬ 
fically  address  the  previously  defined  problem  areas. 

APPLICATIONS 

Design  of  dialogue  language;  evaluation  of  query  languages. 

CONSTRAINTS 

A  number  of  questions  which  will  provide  important  information  to  de¬ 
signers  have  not  yet  been  researched  (Ref.  3),  including; 

•  Effects  of  frequency  of  use  on  query  language  choice. 

•  Amount  of  instruction  required  in  other  languages  to  achieve  the 
same  level  of  competence 

•  Degree  of  threat  which  formal  query  languages  pose  to  potential 
users. 

•  The  proportion  of  invalid  or  incorrect  query  statements  which  a  user 
will  tolerate  prior  to  rejection  of  the  language  or  system. 

•  Acceptability  of  a  restricted  subset  of  English  as  query  language. 

KEY  REFERENCES 

*1.  Ehrenreich,  S.  L.  (1981).  Query  languages:  Design  recommendations 
derived  from  the  human  factors  literature.  Human  Factors,  23(6), 
709-725. 

2.  Gould,  J.  D.,  &  Ascher,  R.  N.  (1975).  The  use 

language  by  nonprogrammers  (RC-5279).  Yorktownl  heights,  UY:  TBM 
Watson  Research  tenter. 


♦Principal  reference 


PROBLEM  AREAS 


COMMENTS 


REFERENCES 


Logical  Quantifiers 

Use  of  logical  quantifiers  (all,  some,  none)  in  the 
presence  of  set  relations  (union,  intersection,  etc.) 
is  very  error-prone. 

Set  Relations 

1 

When  sets  of  elements  are  related  in  a  complex  way, 
human  interpretation  of  the  relationship  is  often 
erroneous. 

Logical  Relations 

Disjunction  (logical  “or")  and  negation  are  error- 
prone  constructs.  Although  this  finding  is  consistent 
with  basic  psychological  research  and  is  probably  gen¬ 
erally  true,  the  principal  study  (Miller,  1974)  in 
which  it  is  related  to  programming  and  query  language 
design  involves  an  atypical  task  in  which  the  subject 
must  compensate  for  absence  of  these  constructs  in  a 
language  by  devising  a  procedural  specification  using 
transfer  of  control. 

Arithmetic 

Relations 

Conversion  of  Inequalities  (e.g.,  from  "over  50"  years 
old  to  "51  or  more"  years  old)  is  error-prone.  Also, 
users  tend  to  use  arithmetic  relations  even  with 
"nominal"  categories,  as  "college  degree  greater  than 
or  equal  to  B.S." 

Semantic  Confusion 
of  Commands 

Errors  occur  when  query  language  has  confusable  com¬ 
mands,  such  as  COUNT  ("how  many  numbers  are  there?") 
and  TOTAL  (what  is  their  sum?). 

\,se  of  Synonyms 
for  File  Names, 
Properties,  etc. 

Users  tend  to  substitute  synonymous  terms  (e.g., 
"employee"  for  "personnel"  file)  which  system  may  not 
recognize. 

Misspelling 

Spelling  errors  are  common  in  query  formulation. 

Also,  users  tend  to  use  an  incorrect  ending  (e.g., 
“employees"  Instead  of  "employee"). 

Omission  of 

Problem-Relevant 

Attributes 

In  formulating  complex  queries,  users  frequently  omit 
one  or  more  of  the  attributes  which  define  the  set. 

Contextual 

Referencing 

If  unconstrained,  users  tend  to  make  contextual 
references  in  queries.  However,  there  is  no  clra'* 
evidence  that  users  fail  to  adapt  to  query  languu:^es 
which  preclude  such  references. 

Ref.  5 


Ref.  5 


Ref.  2 


Ref.  2 


Ref.  5 


Ref.  3 
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TABLE  16.  GUIDELINES  FOR  QUERY  LANGUAGE  DESIGN 


GENERAL  RECOMMENDATIONS 
Data  Organization 

0  Match  user's  perception  of  natural  organization 
0  Use  single  representation  of  data 

Quantifiers 

0  Minimize  use  of  quantification  terms,  except  ‘NO"  and  “NONE'' 

0  When  quantifiers  are  required 

-  Design  quantifiers  for  distinctiveness 

-  Provide  set  of  statements  for  user  selection 

Feedback  of  Query 

0  Rephrase  and  display  query  before  execution 
0  Provide  override  option  of  this  feature  for  experienced  users 

Abbreviations 

0  Truncate  to  form  abbreviations,  except  commonly  known  abbreviations 
0  Three  to  five  characters  In  length 
0  All  abbreviations  must  be  unique 
0  User  should  know  abbreviation  logic 

Dialogue  Transaction 

0  System  messages  should  be  In  directly  usable  form 

0  Provide  prompts  or  reminders  of  current  state  of  transaction  development 
0  All  Information  for  user  determination  of  present  system  states  should  be  In 
single  transaction 

0  Periodically  recap  lengthy  sequences  of  transactions 
0  Information  should  be  In  the  form  limedlately  needed 
0  Queries  which  are  frequently  used  should  be  easy  to  conduct 
0  Feedback  should  Include  receipt  of  query  and  anticipated  response  time 

SPECIAL  RECOMMENDATIONS  -  FORMAL  QUERY  LANGUAGES 

Layering 

0  Language  features  should  be  partitioned  Into  groups  or  layers 
0  Easiest  .layer  should  stand  alone  and  be  Intended  for  casual  users 
0  Layers  should  Increase  In  complexity  for  more  sophisticated  users 

Semantic  Confusion 

0  Avoid  operators  such  as  “or  more*  and  ‘or  less" 

0  Operators  should  be  given  semantically  similar  names 
0  Names  of  operators  should  be  unique  and  self-explanatory 

Term  Specificity 

0  Global  terms  are  not  recommended  for  beginning  users,  except  where  globally 
described  data  are  retrieved  together  frequently 

SPECIAL  RECOMMENDATIONS  -  INFORMAL  QUERY  LANGUAGES 

Clarification  Dialogue 

0  System  should  clarify  poorly-stated  queries  rather  than  reject  them 
0  Systems  should  guide  user  In  formulation  of  properly  stated  query 

Quasi-Natural  Language 

0  Requires  narrow  and  well-defined  systems  task 


3.  Miller,  L.  A.,  &  Becker,  C.  A.  (1974).  Programming  In  natural 
language  (RC-5137).  Yorktown  Heights,  NY:  IBM  Watson  Research 
Center.  (NTIS  No.  AO  A003  923) 

*4.  Ramsey,  H.  R.,  S  Atwood,  M.  E.  (1974).  Human  factors  in  computing 
systems:  A  review  of  the  literature  (SAt-7§-lll-DEN) .  Englewood, 
TJiyi  Science  Applfcations,  Inc.  (hlYtS  AD  A075  679). 

5.  Reisner,  P.  (1977).  The  use  of  psychological  experimentation  as  an 
aid  in  the  development  of  a  query  language.  IEEE  Transactions  on 
Software  Engineering,  SE-3,  218-229. 

6.  Thomas,  J.  C.',  i  Could,'  J.'  0.  (1975).  A  psychological  study  of 
query  by  example.  AFIPS  Conference  Proceedings,  44,  439-445. 

CROSS  REFERENCES 

2.  Basic  properties  of  person-computer  dialogue;  3.  Comparison  of  ap¬ 
proaches  to  person-computer  dialogue;  4.  Major  data  models  in  data  base 
systems;  12.  Designing  for  the  casual  or  infrequent  user;  16.  Comparison 
of  query  languages:  query-by-example,  SEQUEL,  and  algebraic  language; 
20.  Error  recovery  in  person-computer  dialogue 


*  Principal  reference 
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16.  COMPARISON  OF  QUERY  LANGUAGES;  QUERY-BY-EXAMPLE, 
SEQUEL.  AND  ALGEBRAIC  LANGUAGE 


KEY  TERMS 

DATA  BASE  SYSTEMS;  DATA  BASE  QUERY  LANGUAGES 
GENERAL  DESCRIPTION 

The  relative  learning  and  application  capabilities  of  Zloof's  query  by 
example  (Ref.  4),  a  structured  English  query  language  (Ref.  1),  and  a 
variation  of  Codd's  Algebraic  Language  (Ref.  2)  were  compared.  Training 
time,  query  time,  query  accuracy,  and  subjective  confidence  ratings  were 
assessed  (see  Table  17). 

Query  formulation  was  found  to  be  aided  by  the  tabular  format  and  the 
lower  ambiguity  of  query-by-example  than  by  the  other  languages.  Query- 
by-example  also  displayed  the  least  fairly-or-very-sure-incorrect  rat¬ 
ings  of  the  three  languages  (see  Figure  8). 


TABLE  17.  COMPARISON  OF  THREE  QUERY  LANGUAGES:  TIME,  ACCURACY,  AND 
SUBJECT  CONFIDENCE  (Source:  Greenblatt  &  Waxman,  1978) 


QUERY  BY  EXAMPLE* 

SEQUEL 

ALGEBRAIC  LANGUAGE 

Training  Time 
( hours:minutes) 

1:35 

1:40 

2:05 

Mean  Total  Exam  Time 
(minutes) 

23.3 

53.9 

63.3 

Mean  Correct  Queries 
(1) 

75.2 

72.8 

67.7 

Mean  Time/Query 
(minutes) 

.9 

2.5 

3.0 

Mean  Confidence/Query 
(1  to  5) 

1.6 

1.9 

1.9 

Confidence  rating  to  correctness  ratio. 
(Source:  Greenblatt  and  Waxman,  1978) 


APPLICATIONS 


Selection  of  query  languages  for  casual  or  infrequent  users;  query 
language  selection  for  systems  where  training  time  is  severely  limited; 
prediction  of  needs  for  query-in-depth  user  aids. 

METHODOLOGY 


Stimulus  and  Viewing  Conditions 

•  Twenty-question  exams  translated  into  the  three  languages;  o  questions 

provided  sample  data  base  and  sample  queries. 

Procedure  and  Experimental  Design 

•  Independent  variable:  Query  language. 

•  Dependent  variables:  Training  time,  exam  time,  percent  correct 
queries,  subjective  ratings  of  confidence. 

•  Observers  (£s)  trained  in  languages  by  review  of  examples  and  in¬ 
structor  feedback. 

•  Three  random  £  groups:  Query  by  Example  (n=7),  SEQUEL  (n=17). 
Algebraic  Language  (n=13). 

EXPERIMENTAL  RESULTS 

•  No  statistically  significant  difference  was  found  in  mean  exam  time 
and  mean  correct  queries  among  the  three  languages  due  to  large 
standard  deviations. 

•  Confidence  ratings  were  statistically  significantly  higher  for  query 
by  example,  but  not  for  SEQUEL  or  algebraic  language. 

CONSTRAINTS 

•  The  query  languages  compared  differ  considerably  in  basic  philosophy 
and  in  details  of  dialogue. 

•  The  present  study  only  addressed  part  of  the  query  process:  encod¬ 
ing  the  query.  The  overall  process  includes:  (1)  information  need, 
(2)  question  formulation,  (3)  approach  planning,  and  (4)  query 
encoding. 

KEY  REFERENCES 

1.  Chamberlin,  D.  D.,  &  Boyce,  R.  F.  (1974).  SEQUEL:  A  structured 
English  query  language.  Proceedings  of  the  Association  of  Computing 
Machinery  Sigfidet  Workshop,  Ann  Arbor,  MI.  249-2^4. 

2.  Codd,  E.  f.  (19/U).  Relational  model  of  data  for  large  shared  data 
bases.  Communications  of  the  Association  of  Computing  Machinery, 

13(g),  337_3g7^ 

*3.  Ureenblatt,  D.,  &  Waxman,  J.  (1978).  User-oriented  query  language 
design.  In  Proceedings  of  Human  Factors  and  Computer  Science  (pp. 
79-102).  Santa  Monica.  CA:  Human  Factors  Society. 


♦Principal  reference 


4.  Zloof,  M.  M.  (1974).  Query  by  example  (RC  4917).  Yorktown  Heights, 
NY:  IBM,  T.  J.  Watson  Research  Center. 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue  design;  15.  Design  recommendations 
for  query  languages 


17.  DATA  ENTRY  DISPLAYS 


KEY  WORDS 

DATA  FORMS;  GUIDANCE  MESSAGES;  FIELD  LABELS;  FORM-FILLING  DATA  DISPLAY; 
DATA  INPUt;  ^EQU^N(^^  CONl'RbL;  U'^-CflMf>0§ei!)  DATA' TWTRV 

GENERAL  DESCRIPTION 

User-composed  data  entry  provides  a  more  flexible  means  of  input  than 
some  of  the  more  limited  dialogue  types,  such  as  menu  selection. 

Greater  variability  in  user  performance  (input  and  error  rates)  results 
from  this  flexibility,  especially  among  infrequent  and  novice  users. 
Table  18  provides  a  set  of  guidelines  for  selection  of  codes,  design  of 
data  fields,  and  use  of  labels  for  optimizing  user  performance  in  data 
entry  tasks. 

APPLICATIONS 

Data  entry  tasks;  form-filling  dialogue;  computer-initiated  dialogue. 
CONSTRAINTS 

0  Guidelines  may  not  be  general izable  to  all  applications. 

0  Some  user  controlled  flexibility  may  increase  efficiency,  such  as 
user  pacing  of  data  input,  control  of  input  sequence,  or  definition 
of  default  values. 

0  Design  of  data  entry  transactions  is  highly  dependent  on  hardware 
design/ selection. 

0  Guidelines  may  not  be  based  on  data  from  empirical  research. 

KEY  REFERENCES 

1.  Smith,  S.  L.  (1980).  Requirements  definition  and  design  guidelines 
for  the  man-machine  interface  in  C3  systems  acquisition. 

rE'Siy-Wan-17?r:"~ge(ffor'd;  HA:  mitre  Corp. - ^ - 

*2.  Smith,  S.  L.,  &  Aucella,  A.  F.  (1983).  Design  guidelines  for  the 
user  interface  to  computer-based  in forma t^onsystems 
rFSP-'m-83-T??)T"ired7oFd;m:  MITRE  Corp. - 

CROSS  REFERENCES 

12.  Designing  for  the  casual  or  infrequent  computer  user;  13.  System 
response  time  and  the  effect  on  user  performance  and  satisfaction;  19. 
Sequence  control  in  person-computer  dialogue;  25.  Presenting  numeric 
data  in  person-computer  dialogue;  27.  Presenting  tabular  data  in  person- 
computer  dialogue;  30.  Abbreviations  and  acronyms 


♦Principal  reference 


TABLE  18.  GUIDELINES  FOR  DESIGN  OF  DATA  ENTRY  DISPLAYS 
(Source;  Smith  &  Aucella,  1983) 


Design  Objectives 

•  Establish  consistency  of  transactions 

•  Minimize  input  actions 

•  Minimize  memory  load  on  user 

•  Ensure  compatibility  of  data  entry  with  data  display 

•  Provide  flexibility  of  user  control  of  data  entry 

Minimal  Keying  for  Character  Entry 

•  Alphanumeric  entries  should  be  single  stroke  of  labeled  keys 

•  Minimize  double-keying  for  special  characters 

•  Automatic  entry  of  leading  zeros  should  be  optional 

•  Eliminate  distinction  between  single  and  multiple  blanks 

Implicit  Prompting  for  Data  Field  Delineation 


(Good)  (Bad) 

LICENSE  NUMBER:  _  ENTER  LICENSE  NUMBER: 

MAKE: .  ENTER  MAKE  (14  characters): 

YEAR/MOOEL:  .  ENTER  YEAR/MODEL  (11  characters); 


•  Mark  fields  with  special  characters 

•  Visually  indicate  fixed  or  maximum  acceptable  entry 

•  Distinguish  required  and  optional  entries 

•  Automatically  justify  entry  and  remove  unused  underscores 

•  Provide  tab  keying  between  fields 

Logical  Format  of  Data  Fields 

•  Data  entry  display  should  be  compatible  with  output  display 

•  Data  entry  display  should  match  source  document  format 

•  Entry  should  follow  logical  sequence  if  no  source  document  exists 

•  Users  should  not  have  to  enter  data  twice 


(Good) 

(Bad) 

Week:  Month 

Year: 

DACODE: 

Social  Security 

Number:  -  - 

SSAN: 

Speed  Limit:  _ 

_ MPH 

LIM:  _ ft.  per  second 

Distance: 

( km/ hr) 

DIST  (4  chars  and  unit) 

Cost:  $ 

COST: 

Use  agreed  terms,  codes,  or  abbreviations  only 

Separate  label  from  field  with  an  exclusive  punctuation  character 

Include  data  format  cues  where  applicable 

Fixed  measurement  units  -  display  in  label 

Variable  measurement  units  -  provide  alternatives  and  space  for 
user  entry 

Use  units  of  measurement  which  are  familiar  to  user 
Do  not  require  user  to  do  any  data  conversions 


18.  COMPARISON  OF  INPUT  TIME  AND  ERRORS  BETWEEN 
POINT-IN  AND  TYPE-IN  DATA  ENTRY 


KEY  TERMS 

INPUT  ERROR;  LIGHTPEN;  JOYSTICK;  ROLLING  BALL;  KEYBOARD 
GENERAL  DESCRIPTION 

This  experiment  measured  the  relative  efficiency  of  type-in  (keying)  and 
point-in  (pointing)  data  entry  methods  in  terms  of  input  speed  and 
accuracy.  The  number  and  kind  of  errors  committed  under  the  two  methods 
were  analyzed.  Analyses  of  both  input  time  and  errors  indicated  statis¬ 
tically  significant  main  effects  of  input  task,  word  density  and  typing 
ability.  Table  19  provides  comparisons  on  input  time  for  all  levels  of 
these  variables.  Tasks  consisting  of  searching  displays  for  words  and 
typing  words  not  displayed  take  longer  to  perform  than  either  tasks 
consisting  of  searching  and  detecting  displayed  words  or  simply  typing 
the  words.  Entry  time  increased  with  lower  typing  skills  and  higher 
word  densities. 

Error  frequencies,  categorized  by  type,  are  presented  in  Table  20. 
Statistical  comparison  of  errors  "or  all  levels  of  the  three  significant 
main  effects  are  presented  in  Table  21.  Mean  error  in  the  point-all 
words  task  was  smaller  than  under  all  other  task  conditions.  Mean  error 
under  the  point-zero  type- three  and  type-all  words  tasks  was  signifi¬ 
cantly  lower  than  the  mean  error  for  the  remaining  input  tasks. 

Significantly  fewer  errors  were  made  under  the  six  word  density  level 
than  under  the  other  three  density  levels,  and  more  errors  were  commit¬ 
ted  under  the  13  word  level  than  under  the  other  three  density  levels. 

Omission  errors  were  committed  less  frequently  than  the  other  error 
types,  while  more  detection  errors  were  made  than  any  other  error  type. 
Fewer  substitution  errors  were  made  than  either  typographical  or  detec¬ 
tion  errors.  No  significant  differences  in  the  incidence  of  redundancy, 
misperception,  or  typographical  errors  were  found. 

The  overall  major  findings  included: 

•  No  significant  difference  in  input  time  between  point-all  and 
type-all  methods,  but  the  input  error  rate  (one  error  per  every  133 
words  entered)  for  the  point-all  task  was  one- seventh  the  error 
rate  (one  error  per  every  18  words  entered)  of  the  type-all  task. 

•  Data  input  by  the  type-in  method  resulted  in  typographical  and 
misperception  errors.  Both  of  these  error  types  were  eliminated 
when  using  the  point- in  method. 

•  An  increase  in  word  density  inhibited  input  performance  by  increas¬ 
ing  input  time  and  error  rate.  The  bulk  of  the  error  increase  was 
the  result  of  a  large  increase  in  detection  errors. 

•  Comparison  of  the  point-all  and  type-all  conditions  with  the  three 
actual  mixed  input  tasks  showed  that  the  factor  of  certainty  of 
input  method,  i.e.,  more  information,  enhanced  performance. 


TABLE  19.  MEAN  INPUT  TIME  DIFFERENCES  BETWEEN  LEVELS  OF 
THE  MAIN  EFFECTS*  (Source;  Earl  &  Goff.  1965) 


(a) 

Input  Tasks 

Point-all  Point-3  Type-0  Type-all 
6.58  7.13  7.50 

Point-2  Type-1 
10.32 

Point-1  Type-2  Point-0  Type-3 
12.34  12.57 

(b) 

Word  Density 

6  Words  10  Words  14  Words 

9.87  11.13  13.20 

18  Words 
14.74 

(c) 

Typing  Ability 

Good  Fair  Poor 

7.33  8.37  8.76 

♦Levels  of  the  factors  connected  by  rule  are  not  significantly  different  at  p<0.01. 


TABLE  20.  FREQUENCY  OF  POINT-IN  AND  TYPE-IN  ERRORS  LISTED 
BY  ERROR  TYPE  (Source:  Earl  &  Goff,  1965) 


CLASSES  AND  TYPES  OF  ERRORS 

N  ERRORS 

%  OF  TOTAL  ERRORS 

Point-in  Errors 

Detection 

300 

41.02 

Substitution 

24 

3.32 

Omission 

3 

0.42 

Total  Point-in  Errors 

327 

45.12 

Type-in  Errors 

Omission 

4 

0.52 

Redundancy 

116 

16.02 

Misperception 

113 

15.62 

Typographical 

164 

22.62 

Total  Type-in  Errors 

397 

54.92 

Total  Errors 


724 


100.0% 


TABLE  21.  MEAN  ERROR  SCORE  DIFFERENCES  BETWEEN  LEVELS  OF 
THE  MAIN  EFFECTS*  (Source:  Earl  &  Goff,  1965) 


(a)  Input  Tasks 


Point-all  Point-0  Type-3 

Type-all 

Point-3  Type-0 

Point-2  Type-1 

Point-1  Type 

0.54 

3.13 

4.00 

7.13 

7.42 

7.96 

(b) 

Word  Density 

6  Words 

10  Words 

14  Words 

18  Words 

4.25 

5.63 

6.33 

9.96 

(c) 

Error  Types 

Omission  Substitution 

Redundancy 

Misperception 

Typographical 

Detection 

0.29 

1.00 

4.70 

4.83 

6.83 

12.50 

*Levels  of  the  factors  connected  by  rule  are  not  significantly  different  at  p<0.01. 

APPLICATIONS 

Selection  of  input  devices  for  data  entry  tasks  in  which  entry  time  or 
errors  are  critical. 

METHODOLOGY 

Stimulus  and  Viewing  Conditions 

•  Simulated  data  entry  console  consisted  of  IBM  electric  typewriter,  two 
rear-projection  source  data  screens,  observer  (0)  ready  light,  and  a 
simulated  data  entry  knob;  •  randomized  lists  oT  unique  3  to  7  character 
words  (printed  console  display  formats  and  photographically  projected 
source  data  sets);  •  four  density  levels:  6,  10,  14,  18  words  per  list; 

•  five  word  arrangements;  vertical,  semi-vertical,  proportional,  semi¬ 
horizontal,  horizontal. 

Procedure  and  Experimental  Design 

•  5x6x4x3x2x2  complete  factorial  within  subject  design. 

•  Independent  variables;  Five  data  arrangements,  6  input  tasks 
(point- in  three  and  type-in  zero  words,  point- in  two  and  type-in  one 
word,  point- in  one  and  type-in  two  words,  point- in  zero  and  type-in 
three  words,  point-in  all  three  words,  type-in  all  three  words), 
four  word  densities,  three  typing  abilities  (Good;  32-73  words  per 
min;  Fair:  17-32  words  per  min;  Poor:  15-17  words  per  min),  sex 
(male,  female),  two  relative  locations  of  keypunch  device  to  opera¬ 
tor  (typewriter  on  right,  typewriter  on  left). 


•  Dependent  variables:  Input  time  (elapsed  time  per  trial)  and  error 
scores  (incorrect  transcription  of  source  data  words  coincident  with 
input  task) . 

•  0  read  source  word  list  from  display  screen;  source  words  appearing 
on  printed  console  display  format  were  marked  (point-in),  unlisted 
words  were  input  on  keypunch  device  (type-in). 

•  24  subjects  tested  twice  in  all  conditions. 

EXPERIMENTAL  RESULTS 

•  Word  arrangement  and  position  of  keyboard  had  no  influence  on  per¬ 
formance. 

•  Input  time:  decreases  as  number  of  point-in  words  decrease  in  mixed 
tasks;  decreases  as  word  density  decreases;  decreases  with  good 
typing  ability. 

•  Detection  errors  were  most  common  (41X  of  all  errors)  followed  by 
typographical  (22. 6i),  redundancy  (16i),  and  misperception  (15.6*) 
errors. 

•  Errors:  Are  minimized  in  point-all  tasks;  decrease  as  word  density 
decreases. 

Reliability 


Input  time:  Input  task  and  word  density  significant  at  .001  level  of 
confidence;  typing  ability  significant  at  .05  level.  Error  scores: 

Input  task,  word  density,  and  error  type  significant  at  .001  level  of 
confidence. 

CONSTRAINTS 

•  Performance  in  mixed  point- in/ type- in  tasks  may  increase  if  £  is 
familiar  with  the  words  contained  in  the  formats. 

•  Visually  separate  and  partial  feedback  displays,  as  a  function  of 
input  task  type,  were  used;  a  unified  feedback  display  may  result  in 
better  performance. 

KEY  REFERENCES 

1.  Earl,  W.  K.,  &  Goff,  J.  0.  (1965).  Comparison  of  two  data  entry 
methods.  Perceptual  and  Motor  Skills,  20,  369-384. 

CROSS  REFERENCES 

17.  Data  entry  displays 
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19.  SEQUENCE  CONTROL  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

USER  INITIATIVE;  EXPLICIT  USER  ACTIONS;  FLEXIBILITY  OF  CONTROL;  USER 
CONtROL 

GENERAL  DESCRIPTION 

The  logic  and  means  of  input  and  output  linkage  into  coherent  trans¬ 
actions,  as  well  as  control  of  interactive  transactions  should  be 
designed  to: 

•  Maintain  consistency  of  control  actions. 

•  Minimize  control  actions  and  user  memory  load. 

•  Be  compatible  with  user  and  task  needs. 

•  Allow  flexibility  of  control  by  the  user. 

The  degree  and  type  of  user  control  must  be  mediated  by  the  type  of  task 
and  the  characteristics  of  the  user.  As  a  general  rule,  however,  user 
control  is  preferable  to  system  (computer)  control. 

Flexibility  is  a  desirable  attribute  of  sequence  control,  provided  the 
designer  heeds  several  cautions:  (1)  Errors  in  sequence  control  should 
be  expected,  just  like  data  entry  errors.  Therefore,  error  correction 
mechanisms  must  be  included  for  both  system-detected  and  user-detected 
errors.  (2)  Total  flexibility  may  not  be  appropriate  for  all  types  of 
users.  Maximum  flexibility  may  be  appropriate  for  experienced  or  pro¬ 
fessional  users,  whereas  it  may  confuse  novice  or  infrequent  users. 
Failure  to  provide  appropriate  levels  of  flexibility  to  match  the  vari¬ 
ous  levels  of  users  will  prove  frustrating  to  the  users  for  whom  the 
system  is  not  designed.  This  issue  can  be  addressed,  partly,  in  the 
selection  of  the  type  of  dialogue  to  be  employed.  Options,  such  as 
multiple  dialogue  types  or  user  selectable  amounts  of  user  control, 
should  be  considered.  These  issues  are  considered  in  the  guidelines 
provided  in  Table  22. 

APPLICATIONS 

Interact Jv;  dialogue  design;  data  base  system  design. 

CONSTRAINTS 

•  The  guidelines  provided  for  sequence  control  may  not  have  been 
empirically  validated. 


TABLE  22.  SELECTED  GUIDELINES  FOR  DESIGN  OF  SEQUENCE  CONTROL 


USER  CONSIDERATIONS 
Minimize  User  Actions 

•  Simplify  control  actions  to  maximum  extent 

•  Oesign  for  minimum  number  of  required  control  entries  consistent 
with  user  abilities 

Match  Ease  of  Sequence  Control  with  Desired  Ends 

•  Frequent  or  urgent  actions  -  easy  and  quick  control 

•  Potentially  destructive  actions  -  distinctive  actions  under  expli¬ 
cit  user  control 

Match  Control  to  Level (s)  of  User  Skill 

•  May  require  mixed  dialogue  or  entry  stacking  option 

Require  Explicit  User  Actions 

•  Computer  should  not  interrupt  user  entries  until  conclusion 

•  Routine  actions  can  benefit  from  computer  control 

Permit  Initiative  and  Control  by  User 

•  Anticipate  all  possible  user  actions  and  consequences 

•  Provide  appropriate  options  for  each  potential  user  action 

•  Avoid  "dead-ends"  in  dialogues 

•  Allow  user  to  interrupt,  defer,  or  abort  transaction  sequences 
User  Pace  Sequence  Control 

•  Design  for  user's  needs,  attention  span  and  time  available 
Prevent  Interference  Between  Simultaneous  Users 

LOGIC  CONSIDERATIONS 

Design  Consistent  Control  Actions  Throughout  a  System 

Control  Actions  Should  be  Independent  of  Prior  Actions 

Base  Linked  Transaction  Sequences  on  User  Task  Analysis 
t  "Logical  unit"  of  user,  not  logical  unit  of  computer  system,  should 
determine  transaction  sequence 

Establish  Consistent  Terminology  for  Instructional  Materials,  On-Line 
Messages  and  Command  Terms 

Offer  Active  Options  Only 


TABLE  22.  SELECTED  GUIDELINES  FOR  DESIGN  OF  SEQUENCE  CONTROL  (Cont.) 


LANGUAGE  CONSIDERATIONS 

Base  Choice  of  Dialogue  and  Design  of  Sequence  Control  on  User  and  Task 

Characteristics 

•  Question-and-answer  dialogue:  for  routine  data  entry  tasks,  where 
data  items  are  known  and  their  ordering  can  be  constrained,  where 
the  user  will  have  little  or  no  training,  and  where  computer  re¬ 
sponse  is  expected  to  be  moderately  fast 

•  Form-filling  dialogue:  when  some  flexibility  in  data  entry  is 
needed,  such  as  the  inclusion  of  optional  as  well  as  required 
items,  where  users  will  have  moderate  training,  and/or  where  com¬ 
puter  response  may  be  slow 

•  Menu  selection:  tasks  such  as  scheduling  and  monitoring  that 
involve  little  entry  of  arbitrary  data,  where  users  may  have  rela¬ 
tively  little  training,  and  where  computer  response  is  expected  to 
be  fast 

•  Function  keys:  tasks  requiring  only  a  limited  number  of  control 
entries,  or  in  conjunction  with  other  dialogue  types  as  a  ready 
means  of  accomplishing  critical  entries  thac  must  be  made  quickly 
without  syntax  error 

•  Command  language:  tasks  involving  a  wide  range  of  user  control 
entries,  where  users  may  be  highly  trained  in  the  interests  of 
achieving  efficient  performance,  and  where  computer  response  is 
expected  to  be  relatively  fast 

•  Query  language:  specialized  sub-category  of  general  command  lan¬ 
guage  for  tasks  emphasizing  unpredictable  information  retrieval  (as 
in  many  analysis  and  planning  tasks),  with  moderately  trained  users 
and  fast  computer  response 

•  Graphic  interaction:  supplement  to  other  forms  of  human-machine 
dialogue  where  special  task  requirements  exist;  effective  implemen¬ 
tation  of  graphic  capabilities  will  require  very  fast  computer 
response 

INPUT/OUTPUT  CONSIDERATIONS 

Computer  Response  Time  Should  Match  Transaction 

•  Faster  response  for  those  perceived  by  user  to  be  simpler 

Entries  Should  Not  Be  Paced  by  Computer  Response  Delays 

•  When  delays  are  unavoidable,  keyboard  should  automatically  lock 

t  Following  lockout,  computer  readiness  should  be  signaled  to  user 

•  User  should  be  provided  with  means  of  aborting  transaction  during 
lockout 

Provide  Unambiguous  Feedback  for  Control  Entries 

•  Signal  completion  of  processing 

t  Unambiguous  feedback  can  be  immediate  execution,  change  in  state  or 
acceptance/  rejection  message 

Design  Sequence  Control  Features  to  be  Distinctive  in  Position  or 

Format 
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KEY  REFERENCES 


1.  Smith,  S.  L.  (1980).  Requirements  definition  and  design  guidelines 
for  the  man-machine  inWface  in  C3  system  acqu^sHtion 
TIl>0-rR-80-l?2);  TeJford,  MAT  ■HURL  Crop.'  (Hm' Al)  AU87  258). 

*2.  Smith,  S.  L.,  St  Aucella,  A.  F.  (1983).  Design  guidelines  for  the 
user  Interface  to  computer-based  Information  systems 
Tr5ir-TR-83-122).  Bedford,  HA:  MITRE  Corp. - 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue  design;  3.  Comparison  of  approaches 
to  person-computer  dialogue 


♦Principal  reference 


20.  ERROR  RECOVERY  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

ERRORS;  OMISSIONS;  FEEDBACK;  DIRECTIONAL  GUIDANCE;  PROMPTING;  ERROR 
CORRECTION 

GENERAL  DESCRIPTION 

Although  SOX  of  all  keying  errors  are  detected  consciously,  person- 
computer  dialogue  design  should  aid  the  user  in  correcting  and 
recovering  from  system- detected  errors.  Recovery  techniques  should 
consider  feedback,  directional  guidance,  temporal  and  spatial  proximity, 
opportunity  for  immediate  correction,  and  availability  of  relevant  docu¬ 
mentation.  The  failure  to  consider  any  of  these  has  varying  negative 
impact  on  the  probability  of  correct  and  rapid  recovery  from  an  error. 

Table  23  incorporates  these  principles  into  guidelines  for  error  detec¬ 
tion,  error  message  design,  and  error  correction.  When  little  attention 
is  given  to  these  considerations,  system  performance  degrades  due  to 
excessive  user  time  spent  searching  for,  and  correcting,  errors.  Error 
recovery  mechanisms  should  be  designed  to  maximize  the  educational/ 
training  aspect,  with  the  intention  of  reducing  future  reoccurrences. 

The  level  of  effort  required  to  correct  errors  should  be  minimized  to 
permit  maximum  user  concentration  on  the  problem-solving  aspects  of 
error  recovery. 

APPLICATIONS 

Dialogue  design;  design  of  data  entry  systems;  design  of  data  base  query 
systems. 

CONSTRAINTS 

•  The  specific  procedures  on  how  to  handle  user  input  errors  and  what 
to  communicate  for  effective  error  recovery  have  not  been  system¬ 
atically  researched. 

KEY  REFERENCES 

*1.  Engel,  S.  E.,  4  Granda,  R.  E.  (1975).  Guidelines  for  man/display 
interfaces  (00.2720).  Poughkeepsie,  NY:  IBM. 

2.  rienaricKS,  0.,  Kilduff,  P.,  Brooks,  P.  Marshak,  R.,  4  Doyle,  B. 

( 1982 ) .  Human  engineering  guidelines  for  management  information 
systems.  Alexandria,  VA:  U.S.  Army  Materiel  Development  and  Readi¬ 
ness  Command. 

CROSS  REFERENCES 

10.  Interface  design  principles  derived  from  human  error  analyses;  17. 
Data  entry  displays;  19.  Sequence  control  in  person-computer  dialogue 


♦Principal  reference 
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TABLE  23.  GUIDELINES  FOR  ERROR  DETECTION,  MESSAGE  DESIGN  AND  CORRECTION 


ERROR  DETECTION 

•  Users  should  be  able  to  stop  and  return  to  previous  levels  of  a 
multi-level  control  process  at  any  point  In  a  sequence  as  a  result 
of  user-detected  error. 

•  Rejected  Inputs  should  result  In  an  error  message  with  highlighting 
of  the  erroneous  portion. 

•  Batched  or  stacked  strings  of  entries  should  be  processed  (executed) 
to  the  point  of  error  and  then  an  error  message  should  be  sent. 

t  Error  messages  should  be  provided  as  soon  as  possible  after  detec¬ 
tion  by  the  system. 

•  For  multiple  errors,  the  number  of  errors  detected  and  their  loca¬ 
tions  should  be  displayed  until  they  are  corrected. 

•  Errors  made  while  correcting  errors  should  result  In  new  error 
messages. 

•  User  Input  errors  should  be  minimized  through  Internal  software 
validation  of  entries,  such  as  detection  of  numerics  entered  In 
alpha  fields. 

ERROR  MESSAGE  DESIGN 

•  System-detected  errors  should  result  In  messages  providing  as  much 
diagnostic  Information  and  remedial  action  as  can  be  Inferred  re¬ 
liably  from  the  error  condition. 

•  Error  messages  should  reflect  the  user's  point  of  view  of  what  Is 
needed  for  recovery. 

•  All  error  message  should  Indicate: 

a.  location  of  error 

b.  nature  of  error 

c.  one  or  more  ways  to  recover  or  where  to  find  out  how  to  recover. 

•  Error  messages  should  appear  as  close  as  possible  to  the  erroneous 
entry. 

•  Error  message  should  be  understandable  and  non- threatening  to  user 
(avoid  computer- jargon,  humorous  or  condemning  messages). 

•  User  should  be  able  to  select  the  amount  of  detail  contained  In 
error  messages;  two  levels  of  messages  will  be  sufficient  for  most 
cases. 

ERROR  CORRECTION 

•  An  easy  means  of  correcting  erroneous  entries  should  be  provided. 

•  When  an  error  has  occurred,  the  system  should  allow  Immediate  cor¬ 
rection. 

•  A  user  should  not  have  to  reenter  an  entire  line  because  of  an  omis¬ 
sion  or  misspelling  of  one  word. 

t  Lines  of  Input  should  be  alterable  during,  as  well  as  after,  entry. 

•  Users  should  be  able  to  stop  and  return,  at  any  point,  to  previous 
levels  of  multi-level  control  processes. 


21.  DESIGN  AND  CONTROL  OF  CURSORS 


KEY  TERMS 

POSITION  INDICATOR;  POSITION  DESIGNATION;  DATA  ENTRY 

GENERAL  DESCRIPTION 

Cursors  provide  position  designation  for  information  to  be  entered  or 
selected  by  the  user.  Table  24  provides  design  considerations  for  five 
types  of  tasks  in  person-computer  dialogue.  In  general,  movable  cursors 
should  be  designed  to: 

•  Be  located  easily  at  random  positions;  be  tracked  easily  while 
moving; 

•  Not  interfere  with  the  symbol /position  being  marked; 

•  Not  distract  or  impair  searches  for  other  displayed  information; 

•  Have  a  consistent  starting  point  within  frame  as  well  as  between 
frames; 

•  Remain  stable  (drift-proof)  until  positioned  or  repositioned; 

•  Be  box  or  block- type  with  optional  3  kHz  blinking. 

APPLICATIONS 

Position  designation  for  user  inputs  and  information  location  or  selec¬ 
tion  markers. 

CONSTRAINTS 

•  Design  of  cursors  and  control  devices  is  a  function  of  task  being 
performed  by  the  user. 

•  Variable  character  size  on  display  requires  variable  step  size  of 
incremental  stepping  cursor. 

•  Incremental  stepping  cursor  should  have  consistent  step  size  in  all 
directions  of  movement. 

KEY  REFERENCES 

*1.  Hendricks,  D.,  Kilduff,  P.,  Brooks,  P.,  Marshak,  R.,  &  Doyle,  B. 

( 1982 ) .  Human  engineering  guidelines  for  management  information 
systems.  Alexandria,'  VA:  U.S.  Army  Materiel  Development  and  Readi¬ 
ness  (Command. 

*2.  Smith,  S.  L.,  &  Aucella,  A.  F.  (1983).  Design  guidelines  for  the 
user  interface  to  computer-based  information  sylems  itSd-Trt-83-122) . 
Bedford;  m:  The  ’Cofp. - 

CROSS  REFERENCES 

31.  Prompting  in  person-computer  dialogue 


♦Principal  reference 


TABLE  24.  SELECTED  DESIGN  CONSIDERATIONS  FOR  POSITION  DESIGNATION  CURSORS 


TASK  TYPE  (as  sole 
or  primary  dialogue 
mechani sm 

DESIGN  CONSIDERATIONS 

PRINCIPAL  CONTROL  DEVICE 

Continuous 

Positioning 

(a)  Rough 

(a)  At  least  20-30  cm  dis- 

Continuously  operable 

placement  in  0.5  sec 

controls: 

•  Thumbwheel 

•  Joystick 

•  Mouse 

(b)  Fine 

(b)  Options  include: 

•  Point  designation 
(like  cross-hairs  or 
gunsight)  feature  is 
desirable 

•  Incremental  stepping 

•  Large  control/display 
ratios 

•  Selectable  vernier 
modes 

Sequential 

User  action  for  cursor  move- 

Programmable  tab  keys 

Positi  oning 

ment  should  be  minimized 

Pointing  and  Item 

Target  area  should  be  as 

Direct  pointing  types 

Selection 

large  as  consistently  possi- 

•  Lightpen 

ble:  Label  area  plus  half 
character  distance  around 

•  Touch  screen 

label 

Highlighting  selected  item 

Keyed  Data  Entry 

Minimize  cursor  positioning 

Integral  to  keyboard 

movements  and  search  time 

f  Function  keys 
t  Joystick 

Automatic  positioning 

More  Than  One  Task 

Cursors  should  be  visually 

Select  by  above  listed  task 

Using  Multiple 

Cursors 

di stinctive 

Minimize  use  of  multiple 
cursors  to  reduce  user  con¬ 
fusion 

Single  device  control  - 

•  Indicate  to  user  which 
cursor  is  being  con¬ 
trolled 

Multiple  device  control  - 

•  Controls  should  be  com¬ 
patible  in  operation 

types 

_ 1 

22.  ON-LINE  DOCUMENTATION 


KEY  TERMS 

HELP;  ERROR  MESSAGES;  USER  GROUPS 
GENERAL  DESCRIPTION 

Off-line  documentation,  as  well  as  on-line  documentation  and  help  se¬ 
quences,  when  designed  according  to  a  single  "style,"  typically  do  not 
provide  adequate  levels  of  information  for  both  novice  and  experienced 
users.  Inclusion  of  on-line  message  layering  or  selectable  message 
levels  can  be  utilized  successfully  to  meet  various  needs.  Table  25 
presents  general  guidelines  for  design  of  documentation  and  help 
sequences. 

Table  26  describes  two  different  approaches  to  designing  on-line  help 
for  two  types  of  interactive  systems:  programmers  and  non-programmers. 
These  approaches  were  empirically  compared  (Ref.  3)  and  the  results 
support  a  benefit  associated  with  the  multiple  message  type  approach. 

The  study  showed  that  seemingly  superficial  differences  in  message  style 
have  a  significant  affect  on  novice  user  performance. 

APPLICATIONS 

Documentation  design;  on-line  help  facility  design. 

METHODOLOGY 

Stimulus  and  Viewing  Conditions 

•  On-line  help  messages  (two  versions  as  described  in  Table  26)  pre¬ 
sented  on  a  DEC  YTIOO  terminal  under  DEC  VAX/VMS  operating  system 
version  2.3. 

Procedure  and  Experimental  Design 

•  Two-group,  between  subject  experiment. 

•  Typical  fully-automated  office  task  involving  computer  file  manip¬ 
ulation:  creation  and  distribution  of  reports  from  pre-written 
material . 

•  Independent  variable:  Style  of  help  and  error  messages. 

•  Dependent  variables:  Objective-number  of  commands  and  time  consumed 
for  task  completion,  errors,  and  accessing  of  system  information; 
subjective-level  of  user  satisfaction. 

a  Thirty-two  paid  observers  (£$);  computer-novices 

EXPERIMENTAL  RESULTS 

•  Ninety-three  percent  (93*)  of  subjects  using  "non-programmer"  style 
completed  the  task,  whereas  20*  In  "programmer"  style  completed  the 
task;  mean  task  completion  time  was  52  min  in  "non-programmer" 
versus  34  min  in  "programmer"  style. 
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TABLE  25.  SELECTED  GUIDELINES  FOR  DESIGN  OF  ON-LINE  AND  OFF-LINE 
DOCUMENTATION  (Source:  Williges  &  Williges,  1984) 


HELP  AND  DOCUMENTATION 

On-line  documentation,  off-line  documentation  and  help  sequences  should 
use  consistent  terminology. 

Off-Line  Documentation 

All  error  messages  should  be  listed  and  explained  in  the  off-line 
system  documentation. 

Every  nonmenu  frame  should  contain  a  reference  to  a  specific  section 
of  off-line  documentation  to  provide  a  ready  source  of  explanation. 

On-Line  Documentation 

After  accessing  help,  the  user  should  be  provided  with  an  easy  way  to 
return  to  the  main  dialogue. 

On-line  access  to  help  facilities  should  be  provided  for  each 
command. 

All  error  messages  should  be  listed  and  explained  in  the  on-line  help 
sequences. 

A  dictionary  of  abbreviations  and  codes  used  should  be  available 
on-line. 

On-line  access  to  a  list  of  system  capabilities  and  subsystems  should 
be  provided.  By  showing  the  system  components,  options,  and 
structure,  the  on-line  reference  capability  permits  the  user  to 
understand  the  use  of  the  system  effectively. 

When  possible,  natural  language,  rather  than  an  hierarchic  menu, 
should  be  used  to  invoke  on-line  documentation. 

If  more  details  are  needed,  the  user  can  ask  for  a  continuation. 
Successive  levels  of  the  HELP  request  can  go  into  greater  detail. 


TABLE  26.  DIFFERENCES  BETWEEN  THE  ON-LINE  HELP  MODIFIED  FOR  NON-PROGRAM¬ 
MERS  AND  THE  SYSTEM  FOR  PROGRAMMERS  (Source:  Magers,  1983) 


PROGRAMMER'S  SYSTEM 

NON-PROGRAMMER'S  SYSTEM 

HELP  command  only 

HELP  command  and  HELP  key 

Keyword  Indexed  Help 

Context-sensitive  Help 

Rigid  rules  for  forming  correct 
HELP  commands 

More  lenient  rules  for  forming 
correct  HELP  commands 

Mostly  reference  Help 

Tutorial  Help  and  reference  Help 

Uses  computer  Jargon 

Reasonably  jargon-free  or  Jargon 
explained 

Uses  mathematical  notation 

Uses  examples 

Error  messages 

Suggested  correction  messages 

No  feedback  when  command 
correct 

Positive  feedback  messages  confirm 
correct  commands 

Unlimited  access  to  all  compu¬ 
ter  commands 

Commands  available  to  novices 
limited 

Precise  command  names  required 

On-line  dictionary  of  command 
synonyms 

Lengthy  Help  "scrolls"  on 
screen 

Help  In  short,  two- thirds  of 
screen- si  zed  frames 

Computer-oriented  Help 

User-task-oriented  Help 

•  Performance  under  "non-programmer”  style  was  significantly  better 
than  in  "programmer"  style:  higher  task  score,  more  commands  per 
min,  fewer  references  to  off-line  documentation  and  fewer  questions 
asked. 

•  Total  number  of  commands  generated  using  "non-programmer"  style  was 
not  greater  than  in  "programmer"  style,  but  they  were  produced 
nearly  twice  as  rapidly  (1.95  per  min  versus  .99  per  min). 

•  Fewer  erroneous  commands  were  generated  using  "non-programmer"  style 
than  using  "programmer"  style.  Less  total  time  (7.4  versus  33.4 
min)  was  spent  generating  erroneous  commands  using  "non-programmer" 
versus  "programmer"  style. 

•  Greater  usage  of  help  commands  was  measured  in  "non- programmer" 
style  than  in  "programmer"  style. 

0  Subjective  evaluation  displayed  significant  preference  for  "non¬ 
programmer"  style  over  "programmer"  style.  Preference  focused  on 
greater  ease-of-use  and  ease-of-learning,  less  frustrating,  less 
complex,  and  less  confusing,  greater  flexibility  and  personal 
control,  more  friendly,  more  on-line  help  and  better  error  messages. 

CONSTRAINTS 

•  Experienced  users  were  not  compared;  novice  users  only. 

•  Guidelines  presented  in  Table  25  may  not  be  empirically  based. 

KEY  REFERENCES 

1.  Brown,  C.  M.,  Burkleo,  H.  V.,  Mangelsdorf,  J.  E.,  Olsen,  R.  A.,  & 
Williams,  A.  R.,  Jr.  (1981).  Human  factors  engineering  criteria  for 
information  processing  systems'!  Sunnyvale,  CK:  Lockheed. 

2.  Galitz,  W.  0.  U981).  Handbook  of  screen  format  design.  Wellesley, 
MA:  q.E.D.  Information  Sciences. 

*3.  Magers,  C.  S.  (1983,  December  12-15).  An  experimental  evaluation  of 
on-line  help  for  non-programmers.  In  Janda,  A.  (Ed.)  Proceedings  of 
CHI-83  Human  Factors  in  Computing  Systems  (pp.  1-10).  New  York: 
Association  for  Computing  Machinery. 

4.  Miller,  L.  A.,  &  Thomas,  J.  C.,  Jr.  (1976).  Behavioral  issues  in 
the  use  of  interactive  systems  (RC  6326).  Yorktown  Heights,  N/:' 

tbit: - 

5.  Parrish,  R.  N,,  Gates,  J.  L.,  Monger,  S.  J.,  &  Sidorsky,  R.  C. 
(1981).  Development  of  design  guidelines  and  criteria  for  user/ 
operator  transactions  with  battlefield  automated  systems.  Volume 
TT:  Provisional  guidelines  and  criteria  for  the  deisfgn  of  user/ 
operator  transactions.  Alexandria,  VA:  0.5.  Army  Research 
Institute. 

6.  Pew,  R.  W.,  4  Rollins,  A.  M.  (1975).  Dialog  specification  proce¬ 
dures  (3129).  Cambridge,  MA:  Bolt,  Beranex  and  Newman,  inc. 

*7.  THTlTges,  B.  H,,  S  Williges,  R.  C.  (1984).  Dialogue  design  con¬ 
siderations  for  interactive  computer  systems.  In  F.  A.  Muckier 
(Ed.),  Human  factors  review:  1984.  Santa  Monica,  CA:  Human  Fac¬ 
tors  Society. 
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CROSS  REFERENCES 


12.  Designing  for  the  casual  or  infrequent  computer  user;  20.  Error 
recovery  in  person-computer  dialogue;  31.  Prompting  in  person-computer 
dialogue 


23.  AIDS  TO  PERSON-COMPUTER  PROBLEM-SOLVING 


KEY  TERMS 

PROBLEM-SOLVING  BEHAVIOR;  PROBLEM  RECOGNITION;  PROBLEM  DEFINITION;  GOAL 

OEFfNTTlOfJ;  smffS7  §eLECfi6lJ;‘SrfEyATIVe  GENWATION;  - 

EVALUAnOH;  ALTEftt^ATIVg  SFUnTlorAWt)  F)<gCUTr0lI;"im?IOiT-WriIS' 

GENERAL  DESCRIPTION 

Problem-solving  with  abstraction  results  in  the  reformulation  of  prob¬ 
lems  into  more  general,  higher-level  terms.  The  aiding  mechanisms  focus 
on  problem  definition  and  selection  of  strategy.  When  no  abstraction  is 
used,  the  solutions  are  directly  related  to  the  problem-solving  behav¬ 
ior;  therefore,  the  focus  is  on  alternative  generation,  evaluation,  and 
execution. 

Search  behavior  is  problem  solution  generation  by  application  of  in¬ 
ference  rules  and  heuristics  to  a  set  of  potential  solutions.  No-search 
problem-solving  involves  identification  and  retrieval  of  solutions  to 
similar  problems  which  were  previously  solved. 

Data-driven  problem-solving  relies  on  problem  recognition  and  alter¬ 
native  evaluation  based  on  domain-dependent  aspects  of  the  problem. 
Conceptually-drivet.  problem-solving  is  dependent  upon  the  problem 
solver's  prior  experience,  focusing  on  problem  recognition  and  alter¬ 
native  evaluation. 

Table  27  relates  these  problem-solving  behaviors  to  mechanisms  for  the 
aiding  of  decision-making. 

APPLICATION 

Selection  of  appropriate  aiding  mechanisms  for  person-computer  problem¬ 
solving. 

CONSTRAINTS 

•  Aiding  mechanisms  are  limited  to  generation  tasks  as  opposed  to 
recognition  tasks. 

•  Specific  task  and  experience  of  user  affect  the  problem-solving 
behavior  that  is  used. 

•  Requirements  analysis  may  identify  more  than  one  type  of  behavior 
exhibited. 

•  Knowledge  of  problem-solving  aids  is  known  and  is  presented  at  an 
abstract  level,  rather  than  as  specific  guidelines. 
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TABLE  27.  RELATIONSHIP  OF  AIDING  MECHANISMS  TO  TYPES  OF  PROBLEM-SOLVING 
BEHAVIOR  (Source:  Ramsey  &  Atwood,  1979) 


AIDING  MECHANISM 


BEHAVIOR  TYPE 
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Alternative  evaluation 


Alternative  generation 


Automatic  action  execution 


Automatic  takeover* 


Better  weighting  of  unreliable  data 


Change  of  problem  representation 


Decision  consistency  improvement 


Decision  strategy  improvement 


Decomposition  and  recombination 


Disruption  of  psychological  set* 


Extended  memory 


Lockout* 


Rapid  trial-and-error 


Strategy  capture 


*Relationship  with  behavior  type  not  Identified  in  original  source. 
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KEY  REFERENCES 


1.  Ramsey,  H.  R.,  i  Atwood,  M.  E.  (1979).  Human  factors  in  computer 
systems:  A  review  of  the  literature  (SAI-79-111-0EM) .  Englewood 


24.  VOICE  VERSUS  WRITTEN  COMMUNICATIONS  FOR  PROBLEM  SOLVING 


KEY  TERMS 

COMMUNICATIONS  MODES;  VOICE  INPUT;  KEYBOARD  INPUT 
GENERAL  DESCRIPTION 

A  series  of  studies  was  performed  to  derive  dialogue  principles  in 
person-person  communication  as  a  basis  for  establishing  principles  for 
person-computer  dialogue.  When  two  people  must  communicate  to  solve  a 
problem,  solutions  are  achieved  more  quickly  with  voice  communications 
than  by  handwriting  or  typewriting.  However,  these  communications  have 
almost  no  syntactical  structure,  and  subjects  using  the  voice  modes 
generated  eight  times  as  many  words  as  subjects  using  the  writing  modes. 

APPLICATIONS 

Designers  of  per son- computer  dialogues,  particularly  those  responsible 
for  constraining  the  behavior  of  the  human  through  software  syntax, 
should  be  aware  of  the  communications  tendencies  of  humans  when  a  syntax 
is  not  imposed.  Designers  or  advocates  of  the  "natural  language  inter¬ 
face"  concept  should  be  aware  of  the  "unruly"  verbal  tendencies  of  human 
problem  solvers. 

METHODOLOGY 

Materials 


A  room  separated  by  a  removable  cloth  panel  contained  a  teletype  console 
and  a  video  monitor. 

Procedure 


Pairs  of  subjects  solved  problems  by  communicating  in  one  of  three  con¬ 
ditions:  (a)  face-to-face  (communication  rich),  (b)  voice  (no-vision), 
(c)  typewriting.  Subjects  in  the  typewriting  condition  were  classified 
as  either  experienced  or  inexperienced  typists.  The  subjects  were 
college  and  high  school  students  who  solved  problems,  such  as  equipment 
assembly,  in  which  one  subject  had  the  assembly  directions  and  the  other 
had  the  parts.  All  communications  were  observed  and  recorded. 

The  independent  variables  were  five  conditions  of  communication:  (1) 
face-to-face,  (2)  voice,  (3)  handwriting,  (4)  typewriter  (experienced), 
and  (5)  typewriter  (inexperienced).  The  dependent  variables  were:  (1) 
time  to  solve  the  problem,  and  (2)  measures  of  communications  content 
and  structure.  Post-analysis  and  intercorrelations  yielded  nine  useful 
measures:  (1)  number  of  messages  generated  by  each  subject,  (2)  number 
of  sentences  generated  by  each  subject,  (3)  number  of  words  per  message, 
(4)  number  of  words  per  sentence,  (5)  percentage  of  sentences  that  were 
questions,  (6)  number  of  words  used  by  a  subject,  (7)  total  number  of 
different  words  used  by  a  subject,  (8)  ratio  of  different  words  to  total 

-96- 


words,  and  (9)  communication  rate  (number  of  words  communicated  per  min 
duri ng  communi cati ons ) . 


EXPERIMENTAL  RESULTS 

Time  for  solving  problems  is  shown  in  Table  28  for  the  five  communica¬ 
tions  types.  The  voice  modes  were  associated  with  faster  problem 
solution  times  than  handwriting  or  typing.  Despite  the  arguments  for 
nonverbal  communication,  the  time  taken  to  solve  problems  by  voice  alone 
was  only  slightly  greater  than  with  face-to-face  communication  (which 
allowed  pointing  and  other  non-verbal  cues). 


TABLE  28.  PROBLEM  SOLVING  TIME  FOR  SEVEN  MEASURES  OF 
COMMUNICATIONS  (Source:  Chapanis,  1975) 


Solution  Time 
in  Minutes 


Number  of 
Messages 


Number  of 
Sentences 


Total  Number 
of  Words 


Total  Number 
of  Different 
Words 


Ratio  of  Dif¬ 
ficult  Words 
to  Total  Words 


Number  of 
Words  Per 
Minute 


COMMUNI¬ 

CATION 

RICH 

1 

VOICE 

HAND¬ 

WRITING 

TYPEWRITING 

EXPERIENCED  INEXPERIENCED 
TYPISTS  TYPISTS 

29.0 

33.0 

53.3 

66.2 

69.0 

230.4 

163.8 

15.9 

27.2 

31.5 

372.6 

275.9 

1 

1 

24.9 

45.8 

44.1 

1,563.8 

j 

1,374.8 

224.8 

322.9 

257.4 

'V 

397.5 

305.9 

118.5 

150.5 

133.4 

.3 

.3 

.6 

.5 

.6 

190.3 

171.2 

17.3 

18.1 

10.2 

Figure  9  enumerates  results  for  seven  measures  of  communications  accord¬ 
ing  to  the  five  experimental  conditions.  The  results  indicate  that 
problem  solving  by  voice  takes  the  least  time,  but  is  wordier  than  other 
modes  of  communication.  In  general,  all  of  the  communications  modes 
studied  involved  rather  "unruly'*  adherence  to  grammatical,  syntactical 
and  semantic  rules. 


COMMUNICATION 

RICH 

VOICE 


HANDWRITING 

TYPEWRITING 

(EXPERIENCED) 

TYPISTS) 

TYPEWRITING 

(INEXPERIENCED 

TYPISTS) 


0  10  20  30  40  50  60  70 

MEAN  TIME  (MINUTES) 


Figure  9.  Problem-solving  time  for  five  communications  types. 
(Source;  Chapanis,  1975) 


CONSTRAINTS 

•  These  data  bear  on  human-computer  dialogue  only  indirectly  and  by 
inference. 

•  The  studies  used  dyads  only. 

•  The  data  do  not  indicate  the  capability  and  limitations  of  humans  to 
comply  with  syntactical  structure,  when  required. 

•  Individual  differences  in  imposing  syntax  on  communications  are  not 
described. 

•  The  tendency  to  avoid  language  structure  in  communications  found  in 
these  studies  is  not  specific  enough  to  formulate  predictions  about 
the  frequency  and  type  of  non-compliance  to  be  expected  when  a  rigid 
syntax  is  imposed,  as  in  person-computer  dialogue  with  early  1980s 
systems. 

KEY  REFERENCES 

1.  Chapanis,  A.  (1975).  Interactive  human  communication.  Scientific 
American,  232 ,  36-42. 

CROSS  REFERENCES 

1.  Steps  in  person-computer  dialogue  design 
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25.  PRESENTING  NUMERIC  DATA  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

NUMERIC  CODES;  NUMBER  PRESENTATION;  DATA  PRESENTATION 

GENERAL  DESCRIPTION 

Well-designed  formatting  of  numerical  information  displays  can  facili¬ 
tate  the  comprehension  and  comparison  of  the  data  by  the  user.  Table  29 

presents  guidelines  for  presentation  of  numeric  data. 

APPLICATIONS 

Display  of  numeric  information  such  as  part  numbers,  telephone  numbers, 

scores  on  a  series  of  tests,  and  storage  dumps;  data  entry. 

CONSTRAINTS 

•  Most  of  these  guidelines  are  not  based  on  experimental  studies; 
others  are  loosely  based  on  empirical  findings. 

KEY  REFERENCES 

1.  Brown,  C.  M.,  Burkleo,  H.  V.,  Mangelsdorf,  J.  E.,  Olsen,  R.  A.,  & 
Williams,  A.  R.,  Jr.  (1981).  Human  factors  engineering  criteria  for 
information  processing  systems"  Sunnyvale,'  CA:  LoclcHeed. 

2.  Engel,  S.  £.,  4  Granda,  R.  E. '(1975).  Guidelines  for  man/display 
interfaces  (TR  00.2720),  Poughkeepsie,  NY:  (6M. 

3.  fialftz, 'W7  0.  (1981).  Handbook  of  screen  format  design.  Welles¬ 
ley,  MA:  Q.E.D.  Information  Science's. 

4.  Martin,  J.  (1973).  Design  of  man-^computer  dialogues.  Englewood 
Cliffs,  NJ:  Prentice-Hall . 

5.  Parrish,  R.  N.,  Gates,  J.  L.,  Monger,  S.  J.,  &  Sidorsky,  R.  C. 
(1981).  Development  of  design  guidelines  and  criteria  for  user/ 
operator  'transactions  with  battlefield  automated  systems.  Vol.  IV: 
P'rovisional  guidelines  and  criteria  for  the  design  ot  user/operator 
transactions.  Alexandria,  VA:  ll.'S.  Army  Research  Institute. 

6.  Pevi,  ft.  U.,  &  Rollins,  A.  M.  (1975).  Dialog  specification  proce- 
dures  (rev.  ed.)  (Report  No.  3129).  Cambridge,  MA:  Bolt,  Beranek 
and  Newman,  Inc. 

7.  Smith,  S.  L.  (1981).  Man^machine  interface  (MMI)  requirements 

definition  and  design  guidelines:  A  progress  report  (fSD-TR-81- 
113)'.  Bedford,'  'MA:  'The  MITRE  Corp. - - 

*8.  Williges,  B.  H.,  &  Williges,  R.  H.  (1984).  Dialogue  design  consi¬ 
derations  for  interactive  systems.  In  F.  A.  Muckier  (Ed.),  Human 
factors  review:  1984.  Santa  Monica,  CA;  Human  Factors  Socfety . 


♦Principal  reference 


Ju 
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TABLE  29.  GUIDELINES  FOR  DISPLAY  OF  NUMERIC  DATA 


Long  Numeric  Sequences 

•  Should  be  displayed  in  groups  of  three  to  four  (where  no  natural 
split  or  no  pre-defined  break  occurs),  as  in  social  security  numbers 
with  a  blank  character  between  them.  (Refs.  142) 


106619751492 

121519411861 

191418651945 

1917 


1066  1914 
1215  1918 
1492  1941 
1861  1945 
1865  1975 


Numeric  Fields 


Lists  of  numbers  without  decimals  should  be  right-justified.  (Refs. 
1.  4.  4  5) 


Lists  of  numbers  with  decimals  should  use  decimal  alignment. 
1) 


(Ref. 


•  Do  not  assume  that  the  user  can  identify  individual  fields  because 
of  past  familiarity;  context  plays  a  significant  role.  Therefore, 
identify  or  label  the  field.  (Ref.  2) 

•  Present  data  fields  in  some  recognizable  order  if  possible,  for  ease 
of  scanning  and  identification.  For  example,  put  historical  dates 
in  chronological  order.  (Ref.  2) 

•  Numeric  codes  should  be  restricted  to  six  or  fewer  digits.  (Ref.  3) 

•  Leading  zeros  should  not  be  required  except  where  needed  for  clari¬ 
ty.  (Refs.  1,  2,  3.  4  7) 

Standardized  Formats 

•  Identical  data  should  be  presented  to  the  user  in  a  standard  and 
consistent  manner,  despite  its  module  of  origin.  (Ref.  2) 

•  Do  not  change  current  accepted  formats.  Change  only  when  task  or 
activity  must  be  clearly  differentiated  from  other  similar  tasks. 
(Ref.  2) 

a  Suggested  standardization  of  basic  data  fields  for  American  civilian 
users;  (Ref.  2) 


Telephone 

Time 

Date 


914-444-0111 

HH;MM;SS,  MM:SS(.S) 

MM/DO/YY 


CROSS  REFERENCES 

26.  Presenting  text  data  in  person-computer  dialogue;  27.  Presenting 
tabular  data  in  person-computer  dialogue 


v,i>  ..l  ,«JV 
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26.  PRESENTING  TEXT  DATA  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

TEXTUAL  DATA;  ALPHANUMERIC;  TEXT  DISPLAY;  INTERACTIVE  DIALOGUE 
GENERAL  DESCRIPTION 

A  good  format  for  text-based  information  can  facilitate  comprehension 
and  comparison  of  the  data  by  the  user.  Table  30  presents  guidelines 
for  presentation  of  text  data. 

TABLE  30.  CONSIDERATIONS  FOR  DISPLAY  OF  TEXT  DATA 


Display  of  Text  Data 

•  Small  screen  -  no  more  than  50-55  characters  per  line  of  data. 

(Refs.  2X3) 

•  Large  screen  -  two  or  more  columns  of  30-35  characters  per  line. 
(Refs.  2X3) 

•  Mixture  of  upper  and  lower  case  preferable.  (Refs.  1,  2,  X  3) 

•  Left  justify  text.  (Refs.  1,  2,  4,  X  5) 

•  Separate  paragraph  by  at  least  one  blank  line.  (Ref.  2) 

•  For  reading  ease,  field  width  should  be  40  characters  or  less. 

(Ref.  3) 

Display  of  Alphanumeric  Data 

•  Each  character  type  should  be  grouped  together  and  not  interspersed. 
(Refs.  2X6) 

•  Strings  of  five  or  more  alphanumerics  should  be  grouped  into  three 
or  four  characters  where  no  natural  split  or  predefined  break  occurs 
or  should  be  grouped  at  natural  breaks.  (Ref.  4) 

Multi-Column  Displays 

•  Right  justified  text  -  separate  columns  by  at  least  eight  spaces. 
(Refs.  2X3) 

•  Left  justified  text  -  separate  columns  by  three  to  four  spaces. 
(Refs.  2X3) 

Grammatical  Style 

•  Statements  should  be  made  in  the  affirmative.  (Refs.  1X3) 

•  Active  voice  should  be  used,  whenever  possible.  Active  voice  is 
generally  easier  to  understand  than  passive  voice.  (Ref.  1) 

•  If  a  sentence  describes  a  sequence  of  events,  the  word  order  in  the 
sentence  should  correspond  to  the  temporal  sequence  of  events. 

(Refs.  1  X  3) 

•  Short  simple  sentences  should  be  used.  (Refs.  1X3) 

•  Sentences  should  begin  with  the  main  topic.  (Refs.  1X3) 


APPLICATIONS 


Computer-assisted  instruction;  word  processing  systems;  text-based 

person-computer  dialogues;  viewdata  systems. 

CONSTRAINTS 

0  Most  of  these  guidelines  are  not  based  on  experimental  studies; 
others  are  loosely  based  on  empirical  findings. 

KEY  REFERENCES 

1.  Brown,  C.  M.,  Burkleo,  H.  V.,  Mangelsdorf,  J.  E.,  Olsen,  R.  A.,  & 
Williams,  A.  R.,  Jr.  (1981).  Human  factors  engineering  criteria  for 
information  processing  systems'!  Sunnyvale,  CA:  Lockheed. 

2.  Engel,  S.  E.,  ^  Granda,  R.  £.  (1975).  Guidelines  for  man/display 
interfaces  UR  00.2720).  Poughkeepsie,  flY:  ISM. 

3.  Galitz,  W.  0.  (1981).  Handbook  of  screen  format  design.  Wellesley, 
MA:  Q.E.O.  Information  Sciences. 

4.  Martin,  J.  (1973).  Oestgn  of  man-computer  dialogues.  Englewood 
Cliffs,  NJ:  Prentice-Hall. 

5.  Parrish,  R.  N.,  Gates,  J.  L.,  Munger,  S.  J.,  &  Sidorsky,  R.  C. 
(1981).  Development  of  design  guidelines  and  criteria  for  user/ 
operator  transactions  with  battlefield  automated  systems.  Vol.  IV: 
Provisional  guidelines  and  criteria  for  the  design  of  user/operator 
transactions.  Alexandria,  VA:  U.5.  Army  Research  Institute. 

*6.  Williges,  B.  H.,  &  Williges,  R.  C.  (1984).  Design  considerations 
for  interactive  computer  systems.  In  F.  A.  Muckier  (Ed.),  Hi^an 
factors  review;  1984.  Santa  Monica,  CA:  Human  Factors  Society. 

CROSS  REFERENCES 

25.  Presenting  numeric  data  in  person-computer  dialogue;  27.  Presenting 

tabular  data  in  person-computer  dialogue;  30.  Abbreviations  and  acronyms 


♦Principal  reference 


27.  PRESENTING  TABULAR  DATA  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 


DATA  TABLES;  ITEM  LISTS 
GENERAL  DESCRIPTION 

Display  of  data  in  tabular  format  facilitates  comprehension  and  com¬ 
parison  of  the  data.  Table  31  presents  guidelines  for  formatting  data 
into  tables. 


TABLE  31.  GUIDELINES  FOR  DISPLAY  OF  TABULAR  DATA 


Formatting  Data  into  Lists 

•  Each  item  should  start  on  a  new  line,  (Ref.  1) 

•  Items  should  be  arranged  in  recognizable  and  useful  order  (Ref.  1), 
such  as; 

Chronological 

Alphabetical 

Sequential 

Functional 

Frequency  of  use 

Importance. 

•  Items  not  used  for  selection  may  be  enumerated  with  "bullets." 

(Ref.  1) 

•  Block  tabular  data  displays,  whenever  possible,  to  reduce  user 
search  time  for  data,  (Ref.  2) 

•  When  a  list  extends  beyond  the  amount  that  can  be  shown  on  one  dis¬ 
play  page,  a  short  message  should  be  provided  to  indicate  that  the 
list  is  not  complete,  (Ref.l) 

Justification  of  Lists 

•  For  rapid  scanning,  lists  should  be  left- justified  and  aligned  ver¬ 
tically.  Subclasses  can  be  indented.  (Ref.  3) 

•  The  computer  should  handle  the  left-  or  right-justification  of  data 
entries  and  the  justification  of  numeric  lists  on  the  decimal  point 
(Ref.  4) 


APPLICATIONS 


Data  to  be  scanned  and  compared  by  the  user. 

CONSTRAINTS 

0  Most  of  these  guidelines  are  not  based  on  experimental  studies; 
others  are  loosely  based  on  empirical  findings. 

0  Graphic  or  tabular  displays  should  offer,  as  an  option,  the  ability 
to  look  at  raw  data  (Ref.  3). 

KEY  REFERENCES 

1.  Brown,  C.  M.,  Burkleo,  N.  V.,  Mangelsdorf,  J.  E.,  Olsen,  R.  A.,  A 
Williams,  A.  R.,  Jr.  (1981).  Human  factors  engineering  criteria  for 
information  processing  systems'!  Sunnyvale,  tK:  Lockheed. 

2.  Cropper,'^.  'G.','  i  Evans,  J.  W.  (1963).  Ergonomics  and  computer 
display  design.'  The  Computer  Bulletin,  12,  94-98. 

3.  Engel,  S.  E.,  &  Granda,  R.  C.  (1975,  December).  Guidelines  for 
man/display  interfaces  (TR  00.2720).  Poughkeepsie,  fTfi  IBM. 

4.  Smith,  S.  L.  (198i,  February).  Man-machine  interface  (MMI)  require- 

ments  definition  and  design  guidelines:  A  progress  report  fESD-YR- 
?r-in)'.' "Bedford,  MA':  "Mmi:  Corp. - 

*5.  Williges,  B.  H.,  &  Williges,  R.  C.  (1984).  Dialogue  design  consi¬ 
derations  for  interactive  computer  systems.  In  F.  A.  Muckier  (Ed.), 
Human  factors  review:  1984.  Santa  Monica,  CA:  Human  Factors 
Society. 

CROSS  REFERENCES 

25.  Presenting  numeric  data  in  person-computer  dialogue;  26.  Presenting 

text  data  in  person-computer  dialogue 


♦Principal  reference 
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GRAPHICS  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

COMPUTER  GRAPHICS;  DISPLAYS;  DATA  GRAPHS;  ANIMATION;  SPATIALLY-ORIENTED 
DATA 

GENERAL  DESCRIPTION 

Graphic  presentations  greatly  aid  interpretation  and  comparison  of 
numeric  or  spatially-oriented  data.  In  Table  32,  guidelines  are  given 
for  design  of  graphic  displays. 

APPLICATIONS 

Spatial  visualization  problems;  problems  with  multiple  interacting 
dimensions;  display  of  numeric  data;  graphical  dialogues. 

CONSTRAINTS 

•  Although  data  in  graphic  form  is  more  easily  inspected  and  compared, 
raw  data  should  be  provided  as  an  option  to  the  user  (Ref.  2). 

•  Most  of  these  guidelines  are  not  based  on  experimental  studies; 
others  are  loosely  based  on  empirical  findings. 

KEY  REFERENCES 

1.  Barmack,  J.  E.,  &  Sinaiko,  H.  W.  (1966).  Human  factors  problems  in 
computer-generated  graphic  displays  (Study  S-234) .  Washi  ngton,  DC: 
Institute  for  Defense  Analyses. 

2.  Engel,  S.  E.,  &  Granda,  R,  E.  (1975).  Guidelines  for  man/display 
interfaces  (TR  00.2720).  Poughkeepsie,  MV:  IbM. 

3.  Foley,  J.  D.,  Wallace,  V.  L.,  &  Chan,  P.  (1981,  January).  The  human 
factors  of  graphic  interaction:  Tasks  and  techniques  (GWU-llST-81- 
Tjr  Washington,  DC:  George  Washington  Oniversii ty. 

4.  Martin,  J.  (1973).  Design  of  man-computer  dialogues.  Englewood 
Cliffs,  NJ;  Prenti ce-Hatt . 

5.  Newman,  W.  M.,  &  Sproull,  R.  F.  (1979).  Principles  of  interactive 
computer  graphics.  New  York,  NY:  McGraw-Hi 1 1 . 

6.  Schutz,  H!  G.  (1961 ) .  An  evaluation  of  methods  for  presentation  of 
graphic  multiple  trends;  Experiment  III.  Human  Factors,  3,  108- 
119. 

*7.  Williges,  B.  H.,  A  Williges,  R.  C.  (1984).  Dialogue  design  consi¬ 
derations  for  interactive  computer  systems.  In  F.  A.  Muckier  (Ed.), 
Human  factors  review:  1984.  Santa  Monica,  CA:  Human  Factors 
5oci ety . 


♦Principal  reference 


TABLE  32.  DESIGN  GUIDELINES  FOR  GRAPHIC  PRESENTATIONS 


Label s 

•  Describe  what  is  being  displayed  -  not  the  name  of  the  display. 
(Ref.  1) 

•  Always  label  axes.  (Ref.  4) 

Axis  Subdivision  and  Scales 

•  Letter  size  used  for  labeling  scales  should  be  independent  of 
scales.  If  display  is  contracted  to  a  smaller  size,  labels  must 
remain  large  enough  to  be  readable.  (Ref.  1) 

•  Units  of  1,  2,  5,  or  10  should  be  used  to  subdivide  scales  -  not  3, 
7,  or  numbers  arbitrarily  obtained  through  division.  (Ref.  1) 

•  Limit  number  of  graduation  marks  to  9.  (Ref.  1) 

•  Number  scales  starting  at  zero.  (Ref.  1) 

•  Increase  magnitude  clockwise  (left -  right;  bottom -  top) 

Displayed  Values 

•  Maximize  contrast  between  values  and  scale  markings.  (Ref.  1) 

•  Multiple  trend  lines  on  single  graph  facilitates  comparison.  (Ref. 
6) 

Symbols 

$  Consider  the  graphics  conventions  familiar  to  user.  (Ref.  5) 
Display  Complexity 

•  Avoid  unnecessary  ornamentation,  unwanted  graphic  patterns  and 
illusions,  and  alignment  flaws.  (Ref.  5) 

Display  Rotation 

•  Center  of  rotation  should  be  center  of  object. 

•  Labels  should  not  rotate  with  object  if  they  will  not  remain 
horizontal . 


CROSS  REFERENCES 

17.  Data  entry  displays;  32.  Screen  layout  and  structuring  of  person- 
computer  dialogue  displays 
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29.  INFORMATION  CODING  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

HIGHLIGHTING;  COLOR  CODING;  SHAPE  CODING;  BLINKING  CODING;  BRIGHTNESS 
CODING; "ALPHANUMERIC  CODING 

GENERAL  DESCRIPTION 

Coding  of  displayed  information  can  increase  the  efficacy  of  interpreta¬ 
tion  by  emphasizing  relationships  between  displayed  data  elements  and  by 
reducing  a  user's  search-and-identifi cation  time.  Table  33  describes 
five  principal  coding  techniques  and  discusses  critical  factors'  for 
selection  of  optimal  codes.  Techniques  are  presented  in  approximate 
order  of  effectiveness,  with  color  coding  being  preferred. 

APPLICATIONS 

Qualitative  information  displays;  quantitative  information  displays. 
CONSTRAINTS 

•  Codes  must  be  meaningful  and  consistent  with  user  expectations  and 
population  stereotypes. 

•  Coding  for  attention-getting  should  not  be  overused,  or  effective¬ 
ness  will  diminish. 

n  Coding  which  will  reduce  legibility  or  increase  transmission  time 
should  not  be  used. 

•  Color  coding  can  be  seriously  degraded  if  ambient  illumination  is 
not  controlled. 

•  Coding,  typically,  should  be  redundant. 

KEY  REFERENCES 

1.  Brown,  C.  M.,  Burkleo,  H.  V.,  Mangelsdorf,  J.  E.,  Olsen,  R.  A.,  & 
Williams,  A.  R.  Jr.  (1981,  June).  Human  factors  engineering  cri¬ 
teria  for  information  processing  systems.  Sunnyvale,  CA:  Lockheed. 
*2.  Engel,  S.  E.,  &  Granda,  R.  E.  11975).  ITui delines  for  man/display 
interfaces  (00.2720).  Poughkeepsie,  NY;  IBM. 

3.  Galitz,  W.  0.  (1981).  Handbook  of  screen  format  design.  Wellesley, 
MA:  Q.E.D.  Information  Sciences. 

4.  Hutchinson,  R.  D.  (1981).  New  horizons  for  human  factors  in  design. 
New  York,  NY;  McGraw-Hill. 

5.  Miller,  L.  A.,  &  Thomas,  J.  C.  Jr.  (1976,  December).  Behavioral 
issues  in  the  use  of  interactive  systems  (RC6326).  Yorktown 
Heights,  NY;  iW. 


Principal  reference 
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Alphanumeric 


Absolute  identifications 


SELECTION  OF  INFORMATION  CODING  TECHNIQUES 


LlHSTATlONb 

DESIGN  GUIDELINES 

Color  blindness  (especially 

Consider  established  color 

red)  in  &t  of  males 

meanings  in  code  selection, 
example: 

Three  to  ten  hue  color 

0  Red  •  Danger 

1  iiiiit 

Maximum  of  eleven  codes 

0  Yellow  •  Caution 

0  Green  *  Normal 

should  be  used 

color  codes  should  be 
unique  and  defined  on  dis- 

Registration  of  overlayed 
colors 

play 

Recommended  colors  (Ref.  1): 

warm  colors  (red,  yellow) 

0  Green  -  principal  color 

generally  appear  larger 

0  White  -  headings 

than  cool  colors  (blue. 

0  Pink  -  alarms 

green)  in  graphics 

0  Yel low  -  related  data 

0  Turquoise/Cyan  >  user 

Color  codes  may  not  trans¬ 
fer  required  information 
to  monochromatic  displays 

Input 

Fifteen  shape  maximum 

Use  of  fewer  shapes  in¬ 
creases  accuracy  of  identi¬ 
fication 

Not  for  use  with  long- 
phosphor  displays 

User-optional  is  preferable 

Blinking  should  cease  after 

Maximum  of  four  different 
blink  rates 

user  response 

Blink  rate  should  match 
user’s  reading  scan  rate 

Binary  coding  is  preferred 

Recommended  blink  rates: 

0  2-3  Ht  with  80  ms  mini¬ 
mum  (Ref.  2) 

0  3-7  Hi  (Ref.  7) 

\0f  or  less  of  display 

Provide  maximum  contrast 

should  be  highlighted  at 

between  items  highlighted 

once 

No  more  than  three  levels 
of  brightness 

and  other  items 

Confusion  of  symbols 

_ 

Avoid  use  of  frequently  con¬ 
fused  character  pairs., 
including: 

0  5-S  0  0-0 

0  1-1  0  Z-2 

6. 


*7. 


*8. 


Parrish,  R.  N.,  Gates.  J.  L.,  Hunger,  S.  J.,  4  Sidorsky,  R.  C. 
(1981).  Development  of  design  auidelines  and  criteria  for  user/ 
operator  transactions  with  battlefield  automated  systems.  Vol.  IV: 
Provisional  guidelines  and  criteria  for  the  design  of  user/ opera toT 
transactions.  Alexandria,  Va:  ll.S.  Army  Research  Institute. 

Ramsey,  H.  R.,  4  Atwood,  M.  E.  (1979).  Human  factors  in  computer 
systems:  A  review  of  the  literature  (SAl-yd-lii-b^Ji) .  Englewood, 
Science  Applications,  Inc.  intis  AD  A075  679) 

Williges,  B.  H.,  4  Williges,  R.  C.  (1984).  Dialogue  design  consi¬ 
derations  for  interactive  computer  systems.  In  Huckler,  F.  A.  (Ed.) 
Human  factors  review:  1984.  Santa  Monica,  CA:  Human  Factors 
Society. 


CROSS  REFERENCES 


25.  Presenting  numeric  data  in  person-computer  dialogue;  27.  Presenting 
tabular  data  in  person-computer  dialogue 


♦Principal  reference 


30.  ABBREVIATIONS  AND  ACRONYMS 


KEY  TERMS 

TRUNCATION;  COMMAND  LANGUAGE;  MNEMONICS;  ALPHANUMERIC  I/O 

GENERAL  DESCRIPTION 

Terse  and  unambiguous  abbreviations  or  acronyms,  when  used  for  input 
tasks,  can  increase  user  satisfaction  and  productivity  by  reducing 
keying  time,  lowering  input  error  frequency,  and  reducing  user  involve¬ 
ment  in  error  recovery  procedures.  For  output  displays,  abbreviations 
reduce  reading  time  and  convey  information  in  less  physical  display 
space.  Unless  thoughtfully  designed,  however,  abbreviations  (even 
simple  truncation)  can  become  confusing  to  the  user  and  negate  the 
potential  performance  benefits.  Table  34  presents  guidelines  for 
successful  design  of  abbreviations. 

APPLICATIONS 

Command  language  design;  alphanumeric  displays;  text  data  entry. 

CONSTRAINTS 

•  Words  which  are  short  (4  letters  or  less)  should  not  be  abbreviated 
unless  a  standard  abbreviation  exists  (e.g.,  V  for  volt). 

•  Critical  actions  should  not  be  made  dependent  upon  a  single  key¬ 
stroke  response  (e.g.,  Y  for  yes  or  N  for  no). 

•  Abbreviations  are  not  suggested  for  displays  (in  general). 

KEY  REFERENCES 

1.  Brown,  C.  M.,  Burkleo,  H.  V.,  Mangeisdorf,  J.  E.,  Olsen,  R.  A.,  & 
Williams,  A.  R.,  Jr.  (1981).  Human  factors  engineering  criteria  for 
information  processing  systems^  Sunnyvale,  cA:  Lockheed. 

2.  Eihrenreich,  S.  L.  (1981).  (fuery  languages:  Design  recommendations 

derived  from  the  human  factors  literature.  Human  Factors,  23, 
709-725.  -  ■“ 

3.  Galitz,  W.  0.  (1981).  Handbook  of  screen  format  design.  Wellesley, 
MA:  Q.E.O.  Information  Sciences. 

4.  Moses,  F.  L.,  S  Ehrenreich,  S.  L.  (1981).  Abbreviations  for  auto¬ 
mated  systems.  Proceedings  of  the  Human  Factors  Society  25th  Annual 
Meeting  (pp.  132-135) .  Santa  iHonIca,  CA:  the  Human  Factors 
Soc’fdt^ 

5.  Parrish,  R.  N.,  Gates,  J.  L.,  Hunger,  S.  J.,  &  Sidorsky,  R.  C. 
(1981).  Developwent  of  design  auideltnes  and  criteria  for  user/ 
opera^  transactions  with  battlefield  automated  sys^s.  ^  Volume 
TV;  l*rovis1onal  guldetjnes  and  criterU  for  the  design  of  user/ 
operator  transactions  (braft  Pinal  Repo'rt,  ‘Phase  t).  Alexandria, 

VaI  U.S.  Army  Research  Institute. 

6.  Pew,  R.  W.,  S  Rollins,  A.  M.  (1975).  Dialog  specification  proce¬ 
dures  (rev.  ed.)  (Report  No.  3129).  Cambridge,  MA:  Bolt,  Beranek 
arid  Newman,  Inc. 
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TABLE  34.  GUIDELINES  FOR  DESIGN  OF  ABBREVIATIONS  AND  ACRONYMS 


General  Guidelines 

•  Provide  option  for  use  of  abbreviations  or  full  coiwnand.  (Refs.  1  & 
5) 

•  Instruct  user  as  to  method  used  by  system  for  selecting  command 
abbreviations.  (Ref.  2) 

•  Definition  of  data-entry  codes  or  abbreviations  by  the  user  should 
be  allowed.  (Ref.  5) 

•  Contractions  should  not  be  used  on  electronic  displays.  (Refs.  1  & 
4) 

Abbreviation  Design 

Abbreviations  should  be: 

•  Limited  to  one  per  word.  (Ref.  1) 

•  Considerably  shorter  than  the  original  term.  (Refs.  1  &  2) 

•  Mnemonically  meaningful.  (Refs.  1,  2,  &  4) 

•  Distinctive  to  avoid  confusion.  (Refs.  1  &  3) 

•  Composed  of  unrestricted  alphabetic  sets  when  alphabetic  data-entry 
is  required.  (Ref.  8) 

•  Consistent  with  unabbreviated  command  input.  (Refs.  1  &  7) 

•  Simple  truncation  when  used  with  command  names.  (Ref.  2) 

Expansion  of  Abbreviations 

•  Abbreviations  should  be  permitted  in  text  entry  and  expanded  later 
by  the  computer.  (Ref.  1) 


*7.  Ramsey,  H.  R.,  &  Atwood,  M.  E.  (1979),  Human  factors  in  computer 
systems:  A  review  of  the  literature  (SAI-79-111-0EN) .  Elnglewood, 
Science  Applications  Inc.  (NITS  AO  A075  679). 

8.  Smith,  S.  L.  (1981).  Man-machine  interface  (MMI)  requirements 
definition  and  design  guidelines;  A  progress  report  (CSd-1'R-8i- 
nrr  Bedford,  MA:  The  MITRE  Corp.  (MTIsTId.  AD  A096  705). 

9.  Smith,  S.  L.,  &  Aucella,  A.  F.  (1983).  Design  guidelines  for  the 
user  interface  to  computer-based  information  systems 
Tl’SlPm-'53-T22  )■.  ffe^fdrj;  TO:  Th'e  TTTTRTTorp; 

10.  Williges,  B.  H.,  &  Williges,  R.  C,  (1983).  Dialogue  design  consi¬ 
derations  for  interactive  computer  systems.  In  F.  A.  Muckier  (Ed.), 
Human  factors  review:  1984.  Santa  Monica,  CA:  Human  Factors 
Society. 

CROSS  REFERENCES 

26.  Presenting  text  data  in  person-computer  dialogue;  27.  Presenting 
tabular  data  in  person-computer  dialogue;  29.  Information  coding  in 
person-computer  dialogue;  31.  Prompting  in  person-computer  dialogue;  33. 
Guidelines  for  mul tipi e- frame  displays;  34.  Design  guidelines  for  multi¬ 
ple-level  displays 


*Principal  reference 


31.  PROMPTING  IN  PERSON-COMPUTER  DIALOGUE 


KEY  TERMS 

CURSOR  FORMS;  COMMAND  LANGUAGE;  INPUT  PROMPTS 
GENERAL  DESCRIPTION 

Prompting,  regardless  of  form,  provides  a  cue  for  required  user  inputs 
in  person-computer  dialogue.  The  effectiveness  of  prompting  can  be 
enhanced  by  designing  the  prompts  to  be  clear  and  understandable,  empha¬ 
sized  by  highlighting,  uniqueness  and  consistent  location.  Table  35 
provides  recommended  prompt  forms  for  various  input  formats. 


TABLE  35.  INPUT  FORMAT  AND  RECOMMENDED  PROMPT  FORMS 


INPUT  FORMAT 

PROMPT  FORM 

General  Purpose 

Commentary  on  Screen 

General  Purpose 

Selectively  Illuminating 
Function  Keys 

Positional  Data 

Tracking  Cross 

Text  String 

Blinking  Cursor 

Numerical  Data 

Quantitative  Scale/Dial 

APPLICATIONS 

System- i ni tiated  requests  for  information  to  be  input  by  user;  struc¬ 
turing  of  command  languages  where  used  by  inexperienced  users. 

CONSTRAINTS 

•  Prompting  form  should  be  selected  as  a  function  of  desired  input- 
type. 

KEY  REFERENCES 

*1. 

♦Principal  reference 


Engel,  S.  E.,  4  Granda,  R.  E.  (1975).  Guidelines  for  man/displaj 
interfaces  (00.2720).  Poughkeepsie,  NYl  idM. 


2.  Foley,  J.  D.,  4  Wallace,  V.  L.  (1974).  The  art  of  graphic  laan- 
raachine  conversation.  Proceedings  of  the  IEEE,  62(4),  462-471. 

*3.  Williges,  B.  H.,  4  Williges,  R.  H.  (1^84).  CTTalogue  design  consi¬ 
derations  for  interactive  computer  systems.  In  F.  A.  Muckier  (Ed.), 
Human  factors  review:  1984.  Santa  Monica,  CA:  The  Human  Factors 
Society. 

CROSS  REFERENCES 

21.  Design  and  control  of  cursors;  32.  Screen  layout  and  structuring  of 
person-computer  dialogue  displays 


♦Principal  reference 


32.  SCREEN  LAYOUT  AND  STRUCTURING  OF  PERSON-COMPUTER  DIALOGUE  DISPLAYS 


KEY  TERMS 

DISPLAYS;  FRAME  DESIGN;  DATA  ENTRY;  SMALL  SCREEN  DISPLAYS 
GENERAL  DESCRIPTION 

The  structuring  of  screen  layout  provides  the  designer  with  an  oppor¬ 
tunity  to  utilize  the  available  display  format  for  presentation  of 
information  which  corresponds  with  the  limits  of  human  perception  and 
memory.  Display  of  too  much  information  at  one  time  can  confuse  users 
and  tax  the  user's  memory.  The  resulting  user  behaviors  include  frus¬ 
tration,  a  high  frequency  of  errors,  and  (perhaps)  eventual  refusal  to 
use  the  system. 

Two  types  of  display  structuring  should  be  considered:  perceptual  or¬ 
ganization  of  data  displays  and  sequential  and/or  hierarchical  organiza¬ 
tion.  Table  36  provides  a  series  of  guidelines  focusing  on  functional 
grouping  and  display  consistency  concepts  which  provide  increased  user 
awareness  of  the  perceptual  organization.  Criteria  for  functional 
grouping  can  range  from  arbitrary,  yet  consistent,  organization  to 
design  based  on  frequency  of  usage  or  optimal  logic  flow.  Details  for 
individual  frame  design  are  provided  in  the  cross  references  listing, 
according  to  data  type. 


TABLE  36.  GUIDELINES  FOR  SCREEN  LAYOUT  AND  STRUCTURING 
(Source:  Williges  &  Williges,  1984) 


Windowing  and  Partitioning  of  Display 

f  The  display  should  not  be  divided  into  many  small  windows.  (Refs.  2 
&  3) 

•  The  user  should  be  permitted  to  divide  the  screen  into  windows  or 
functional  areas  of  an  appropriate  size  for  the  task.  (Ref.  6) 

•  Dashed  lines  may  be  used  to  segment  the  display.  (Ref.  4) 

•  The  unused  areas  should  be  used  to  separate  logical  groups,  rather 
than  having  all  the  unused  area  on  one  side  of  the  display.  (Ref. 

1) 

•  In  data  entry  and  retrieval  tasks,  the  screen  should  be  functionally 
partitioned  into  different  areas  to  discriminate  among  different 
classes  of  information  for  commands,  status  messages,  and  input 
fields.  (Refs.  3  &  5) 

•  To  enhance  important  or  infrequent  messages  and  alarms,  they  should 
be. placed  in  the  central  field  of  vision  relative  to  the  display 
window.  (Refs.  2  A  10) 


TABLE  36.  GUIDELINES  FOR  SCREEN  LAYOUT  AND  STRUCTURING  (Cont.) 
(Source:  Williges  &  Williges,  1984) 


Organization  of  Fields 

•  The  organization  of  displayed  fields  should  be  standardized.  Func¬ 
tional  areas  should  remain  in  the  same  relative  location  on  all 
frames.  This  permits  the  users  to  develop  spatial  expectancies. 

For  example,  functional  areas  reserved  for  a  particular  kind  of  data 
should  remain  in  the  same  relative  display  location  throughout  the 
dialogue.  (Refs.  1,  2,  3,  &  7) 

•  For  data-entry  dialogues,  an  obvious  starting  point  in  the  upper- 
left  corner  of  the  screen  should  be  provided.  (Ref.  3) 

•  To  avoid  clutter,  data  should  be  presented  using  spacing,  grouping 
and  columns  to  produce  an  ordc'ly  and  legible  display.  (Refs.  1  & 

3) 

•  Data  should  be  arranged  in  logical  groups:  sequentially,  function¬ 
ally,  by  importance,  or  by  frequency.  (Ref.  1) 

•  Logically  related  data  should  be  clearly  grouped  and  separated  from 
other  categories  of  data.  On  large,  uncluttered  screens,  the  dis¬ 
play  or  functional  areas  should  be  separated  by  blank  spaces  (3-5 
rows  and/or  columns).  On  smaller  and/or  more  cluttered  screens, 
structure  can  be  defined  by  other  coding  techniques,  such  as  using 
different  surrounding  line  types,  line  widths,  intensity  levels, 
geometric  shapes,  color,  etc.  (Refs.  2,  3,  &  10) 

•  Data  should  be  arranged  on  the  screen  so  that  the  observation  of 
similarities,  differences,  trends,  and  relationships  is  facilitated 
for  the  most  common  uses.  (Ref.  1) 

Instructions  and  Supplemental  Information 

0  In  computer- initiated  dialogues,  each  display  page  should  have  a 
title  that  indicates  the  purpose  of  the  page.  (Ref.  8) 

0  Instructions  should  stand  out.  For  example,  instructions  may  be 
preceded  by  a  row  of  asterisks.  (Refs.  1  &  4) 

0  Instructions  on  how  to  use  a  data-entry  screen  should  precede  the 
screen  or  appear  at  the  top  of  the  test.  (Ref.  3) 

0  Instructions  concerning  how  to  process  a  completed  data-entry  screen 
should  appear  at  the  bottom  of  the  screen.  (Ref.  3) 

0  Symmetrical  balance  should  be  maintained  by  centering  titles  and 
graphics.  (Ref.  3) 

0  In  data  entry  and  retrieval  tasks,  the  last  four  lines  on  each  dis¬ 
play  page  should  be  reserved  for  messages,  to  indicate  errors,  com¬ 
munication  links,  or  system  status.  (Ref.  8) 

0  When  command  language  is  used  for  control  input,  an  appropriate 
entry  area  should  be  provided  in  a  consistent  location  on  every 
display,  preferably  at  the  bottom  of  the  screen  if  the  cursor  can  be 
conveniently  moved  there.  (Ref.  9) 

0  Displays  should  be  designed  so  that  information  relevant  to  sequence 
control  should  be  distinctive  in  position  and/or  format.  (Ref.  9) 

0  Frequently  appearing  commands  should  appear  in  the  same  area  of  the 
display  at  all  times.  (Ref.  2) 


APPLICATION 

Format  of  information  displays;  small  screen  displays  (£4000  charac¬ 
ters)  . 

CONSTRAINTS 

t  Guidelines  may  not  be  based  on  empirically  validated  research. 

•  Only  required  information  should  be  displayed  to  avoid  information 
overload  or  display  clutter.  Additional  information  should  be 
available  on  user  request. 

KEY  REFERENCES 

1.  Brown,  C.  M.,  Burkleo,  H.  V.,  Mangelsdorf,  J.  E.,  Olsen,  R,  A.,  & 
Williams,  A.  R.,  Jr.  (1981).  Human  factors  engineering  criteria  for 
information  processing  systems^  Sunnyvale,  CA:  Lockheed. 

2.  Engel ,  S.  E. ,  i  Granda,  R.  E.  (1975).  Guidelines  for  man/display 
interfaces  (00.2720).  Poughkeepsie,  NYl  iSM^ 

3.  Galltz,  W.  0.  (1981).  Handbook  of  screen  format  design.  Wellesley, 
MA:  Q.E.D.  Information  Sciences. 

4.  Martin,  J.  (1973).  Design  of  man-computer  dialogues.  Englewood 
Cliffs,  NO:  Prentice-Hall . 

5.  Miller,  L.  A.,  i  Thomas,  J.  C.,  Jr.  (1976).  Behavioral  Usues  in 
the  use  of  interactive  systems  (RC  6326).  Yorktown  Heights,  NY: 

mr. - 

6.  Newman,  W.  M.,  &  Sproull,  R.  F.  (1979).  Principles  of  interactive 
computer  graphics.  New  York,  NY:  McGraw^Hflll . 

7.  Parrish,  R.  M. ,  Gates,  J.  L.,  Munger,  S.  J.,  &  Sidorsky,  R.  C. 
(1981).  Development  of  design  guidelines  and  criteria  for  i^ser/ 
operator  transactions  with  battlefield  automated  systems.  Volume 
TV:  Provisional  guidelines  and  criteria  for  the  design  of  user/ 
operator  transactions  (Draft  Einal  Report,  Phase  1).  Alexandria, 

JK:  U.  S.  Army  Research  Institute. 

8.  Pew,  R.  W.,  &  Rollins,  A.  M.  (1975).  Dialog  specification  proce- 
dures  (3129).  Cambridge,  MA:  Bolt,  Beraneic  and  Newman. 

9.  Smi th ,  S.  L.  (1981).  Man-machine  interface  (MMI)  requirements 
definition  and  design  guTdelfnes:  A  progress  report  (ESD-TR-81- 
113 ) .  'ffedfoVd,  ITC:'  '  ■MITPf.  THTf?  'No.  AD' Wr7&5T" 

10.  Tullis,  T.  S.  (1981).  An  evaluation  of  alphanumeric,  graphic,  and 
color  information  displays.  Human  Factors,  23,  541-550. 

*11.  Williges,  B.  H.,  &  Williges,  R.  C.  (1984).  Dialogue  design  consi¬ 
derations  for  interactive  computer  systems.  In  F.  A.  Muckier  (Ed.) 
Human  factors  review:  1984.  Santa  Monica,  CA:  Human  Factors 
Society. 


♦Principal  reference 


CROSS  REFERENCES 


17.  Data  entry  displays;  21.  Design  and  control  of  cursors;  25.  Present¬ 
ing  numeric  data  in  person-computer  dialogue;  26.  Presenting  text  data 
in  person-computer  dialogue;  27.  Presenting  tabular  data  in  person- 
computer  dialogue;  28.  Graphics  in  person-computer  dialogue;  29.  Infor¬ 
mation  coding  in  person-computer  dialogue;  30.  Abbreviations  and  acro¬ 
nyms;  31.  Prompting  in  person-computer  dialogue;  33.  Guidelines  for 
mul tipi e- frame  display  design;  34.  Design  guidelines  for  multiple-level 
displays;  35.  Windowing  versus  scrolling  on  visual  display  terminals 


I 
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INILRFRAMt  CUNbiDtRATIUNb;  MULT I-HRAML;  HILRARCHIGAL  bIRUUIUKLb; 


SEQUENCE  CONTROL;  BRANCHING  MENUS 


GENERAL  DESCRIPTION 


The  guidelines  were  synthesized  from  known  human  factors/psychological 
principles,  experimental  studies,  customer/user  comments,  and  informal 
studies.  Table  37  lists  guidelines  for  display  of  multiple  frames  in 
series  to  minimize  dependence  on  user's  memory, 

APPLICATIONS 


Use  of  more  than  one  frame  for  data  display  or  entry;  sequence  control 

in  hierarchical  or  branching  menus. 

CONSTRAINTS 

•  Guidelines  are  not  standards:  consider  modifications  required  by 
specific  system/application  needs. 

•  Guidelines  cannot  provide  quantification  without  empirical  study. 

•  Recent  systematic  studies  of  interface  design  may  provide  more 
detailed/updated  guidelines. 

•  Multiple  frame  display  design  must  also  consider  single  frame  dis¬ 
play  guidelines. 

•  Pilot  testing  is  desirable  to  validate  guidelines  in  application 
usage , 

KEY  REFERENCES 


1,  Engel,  S.  E.,  &  Granda,  R.  E.  (1975).  Guidelines  for  man/display 
interfaces  (00.2720).  Poughkeepsie,  NY"!  IBM  Poughkeepsie  Labora- 
tory , 

CROSS  REFERENCES 


34.  Design  guidelines  for  multiple-level  menus 


TABLE  37.  LISTING  OF  GUIDELINES  FOR  MULTIPLE-LEVEL  DISPLAYS 
(Source:  Engel  &  Granda,  1975) 


•  Provide  present  and  maximum  locations  on  viewed  portion  when  scrolling 
a  large  logical  frame.  Example;  “Line  72  of  117" 

•  Provide  user  control  of  amount,  format  and  complexity  of  displayed 
system  information. 

•  Display  prose  text  in  upper  and  lower  case.  Labels,  titles  or 
attention-getting  message,  use  upper  case  only. 


ALL  UPPER  CASE  TEXT 
IS  HARDER  TO  READ 
THAN  A  MIXTURE  OF 
UPPER  AND  LOWER  CASE. 


Normal  reading  is 
easier  if  the  text 
is  in  both  upper 
and  lower  case. 


•  Minimize  users'  need  to  remember  data  from  frame  to  frame;  provide 
visible  audit  trail  of  choices. 


First  Frame 


Second  Frame 


Third  Frame 


Pick  one: 
FORTRAN 
PL/ 1 
GPSS 


GPSS 

Pick  one: 
ADVANCE 
TRANSFER 
UNLINK 


GPSS  -  TRANSFER 
Pick  one: 
Fractional 
Pick 

Unconditional 


•  Use  consistent  meanings  and  context  of  technical  words.  Consider 
user's  viewpoint,  not  programmer's. 

•  Keep  lists  small  (4-6  items)  to  increase  comprehension  of  listed 
items. 

•  Standardize  spatial  position  of  appearing/disappearing  screen  items: 

a.  Commands  in  same  location  on  screen 


b.  List  items  in  same  location  in  list  regardless  of 
number  of  items. 


•  Maintain  system  control  of  essential  data,  text,  formats,  etc.,  not 
user  control. 


34.  DESIGN  GUIDELINES  FOR  MULTIPLE-LEVEL  DISPLAYS 


KEY  TERMS 

MENU  DIALOGUE;  MULTI-PAGE  DISPLAYS;  MULTI-FRAME 
GENERAL  DESCRIPTION 

Displays  with  multiple-levels  which  the  user  must  negotiate  to  accom¬ 
plish  a  task  must  provide  mechanisms  for  accuracy  and  ease-of-use. 
Table  38  provides  a  checklist  of  critical  design  considerations. 


TABLE  38.  MULTIPLE-LEVEL  DISPLAY  CONSIDERATIONS 
(Source:  Hendricks  et  al.,  1982) 


Display  Levels 

Yes 

Not 

Applicable 

Not 

Known 

No 

If  the  system  has  multiple  display 
levels,  does  the  system; 

a. 

Minimize  the  number  of  levels 
required? 

b. 

Provide  priority  access  to  the 
more  critical  display  levels? 

c. 

Provide  the  user  with  information 
about  the  current  position  within 
the  sequence  of  levels? 

d. 

Insure  similarity,  wherever  pos¬ 
sible,  between  display  formats  at 
each  level? 

e. 

Supply  all  data  relevant  to  mak¬ 
ing  an  entry  on  one  display 
frame? 

APPLICATIONS 

Interactive  dialogue  requiring  use  of  multiple  dialogue  levels;  hier¬ 
archical  or  branching  dialogue;  computer  initiated  questioning,  form¬ 
filling  or  menu  selection  dialogue. 


CONSTRAINTS 


•  Guidelines  are  not  standards:  consider  modifications  required  by 
specific  system/ application  needs. 

•  Guidelines  cannot  provide  quantification  without  empirical  study. 

•  Multiple  frame  display  design  must  also  consider  single  frame  dis¬ 
play  guidelines. 

t  Pilot  testing  is  desirable  to  validate  guidelines  for  specific 
applications. 

KEY  REFERENCES 

1.  Henricks,  D.,  Kilduff,  P.,  Brooks,  P.,  Marchak,  B.,  &  Doyle,  B. 
(1982).  Human  engineering  guidelines  for  management  information 
systems.  Alexandria,  VA:  U.S.  Army  Materiel  Development  and  Readi¬ 
ness  Command. 

CROSS  REFERENCES 

33.  Guidelines  for  multi  pie- frame  display  design 


35.  WINDOWING  VERSUS  SCROLLING  ON  VISUAL  DISPLAY  TERMINALS 


KEY  TERMS 

VIDEO  DISPLAY  INFORMATION;  DATA  DISPLAY  MOVEMENTS;  HIERARCHIC  DATA 

BIS^L'ATS - 

GENERAL  DESCRIPTION 

Two  conceptualizations  of  data  display  restriction  are  common  when 
available  data  exceeds  the  display  capability  of  a  video  display  ter¬ 
minal  (VDT):  (1)  windowing  and  (2)  scrolling.  The  windowing  concept 
allows  selection  of  views  of  "stationary"  data,  whereas  scrolling  pro¬ 
vides  a  movement  of  the  data  observable  through  a  "stationary"  VDT. 
Figure  10  diagramatically  shows  differences  between  windowing  and 
scrolling. 


Figure  10.  Data  network  overview  showing  windowing  page  boundaries 

(dashed  lines)  and  an  example  scrolling  page  (solid  lines). 
(Source;  Brooke  and  Duncan,  1983) 


"Intuitive"  advantages  of  each  concept  have  resulted  in  the  adoption  of 
both  types  of  data  displays  in  various  systems.  Empirical  research 
tends  to  indicate  a  population  stereotype  in  favor  of,  and  a  superiority 
of,  the  windowing  concept.  Conclusive  findings  in  applied  problem¬ 
solving  tasks,  however,  are  pending.  Windowing  is  believed  to  provide  a 
more  optimal  outline  of  the  overall  structure,  thus  reducing  the  memory 
load  on  the  user.  Table  39  describes  the  major  finding  of  windowing 
versus  scrolling. 


TABLE  39.  MAJOR  FINDINGS  OF  WINDOWING  VERSUS  SCROLLING  RESEARCH 


Consistent  user  performance  is  facilitated  by  restricted  views,  rather 
than  unrestricted  views,  of  system  information. 

When  allowed  to  choose  system  modes,  more  novice  users  chose  window 
mode. 

Window  displays  are  more  efficient  than  scrolling  displays;  users  per¬ 
formed  tasks: 

•  in  less  time 

•  with  fewer  number  of  moves 

•  with  less  error 

Explanation  and  demonstration  of  display  modes  does  not  affect  perfor¬ 
mance. 


The  use  of  key top  scroll  figures 
does  not  improve  performance. 


as  opposed  to  arrows 


APPLICATIONS 

Selection  of  video  display  modes;  engineering  data  base  search  strate¬ 
gies. 

METHODOLOGY 

Stimulus  and  Viewing  Conditions 

Study  1  (Ref.  2):  •  Display  of  number  vector  (horizontal)  and  letter 

vector  (vertical)  intersecting  at  "12-13"  and  "L-M";  t  initial  position: 
intersection. 

Study  2  (Ref.  1):  •  Logic  network  -  four  rows  x  six  columns;  •  display 

restricted  by  windows  or  scrolling  (see  Fig.);  •  initial  position:  top 
right  cell . 

Procedure  and  Experimental  Design 
Study  1  (Ref.  2): 

•  Independent  variables:  display  concept  (Self-defined  -  Observers 
(Os)  defined  mode  in  which  the  system  operated.  No  explanation  of 
tRe  window  or  scroll  concept  was  given;  Window/ concept  -  Os  were 
given  an  explanation  and  demonstration  of  the  window  conc?pt  and 
were  constrained  to  operate  in  the  window  mode;  Window/no  concept  - 
2s  were  constrained  to  operate  in  the  window  mode,  but  were  given  no 
'explanation  or  demonstration  of  the  window  concept;  Scroll /concept  - 
Os  were  given  an  explanation  and  demonstration  of  the  scroll  concept 


and  were  constrained  to  operate  in  the  scroll  mode;  Scroll /no  con¬ 
cept  -  Os  were  constrained  to  operate  in  the  scroll  mode  without  an 
explanaTion  or  demonstration  of  the  scroll  concept). 

•  Dependent  variables:  Time  for  problem  solution;  number  of  moves. 

•  O's  task:  Move  display  to  display  requested  data  (example:  show 
■^x"  and  "20"). 

•  £s:  28  high  school  students. 

Study  2  (Ref.  1): 

•  Independent  variables;  Type  of  display  (whole,  windowing,  scrol¬ 
ling),  ability  on  pre-test. 

•  Dependent  variables:  Solution  time,  efficiency. 

•  O's  task:  logic  tree  fault  finding. 

•  7s:  23  high  school  and  undergraduate  college  students. 

EXPERIMENTAL  RESULTS 

Study  1  (Ref.  2): 

•  Significantly  greater  number  of  novice  users  (79t)  chose  windowing 
mode. 

•  Windowing  groups  performed  significantly  faster  and  with  fewer 
number  of  moves  overall. 

•  Explanation  and  description  of  the  appropriate  concept  did  not  have 
a  significant  affect  on  performance. 

•  Type  of  key top  marking  did  not  have  a  significant  effect  on  perfor¬ 
mance  (determined  in  separate  study). 

Study  2  (Ref.  1): 

•  Windowing  format  improved  the  efficiency  of  the  fault  diagnosis  task 
rather  than  ensuring  correct  problem  solution. 

•  Restricting  the  proportion  of  information  displayed  substantially 
restricts  between  subject  variance  in  the  fauH  finding  measures. 

CONSTRAINTS 

•  Conclusions  are  based  on  limited  empirical  study. 

•  Applicability  of  these  findings  to  experienced  users  of  computers  or 
specific  systems  is  unknown. 

KEY  REFERENCES 

*1.  Brooke,  J.  B.,  S  Duncan,  K.  D.  (1983).  A  comparison  of  hierarchi¬ 
cally  paged  and  scrolling  displays  for  fault-finding.  Ergonomics, 
26(5),  465-477. 

*2.  'Bury,  K.  F.,  Boyle,  J.  M.,  Evey,  R.  J.,  4  Neal,  A.  S.  (1982). 
Windowing  versus  scrolling  on  a  visual  display  terminal.  Human 
Factors,  24(4),  385-394. 

CROSS  REFERENCES 

19.  Sequence  control  in  person-computer  dialogue;  21.  Design  and  control 

of  cursors 


♦Principal  reference 


36.  GUIDELINES  FOR  USE  OF  NONCRITICAL  AUDITORY  SIGNALS 


KEY  TERMS 

ALARMS;  BELL 
GENERAL  DESCRIPTION 

Auditory  signals  can  be  used  to  supplement  interactive  visual  displays 
in  critical  and  noncritical  situations.  They  are  best,  however,  for 
critical  situations.  Auditory  signals  should  be  used  in  situations 
where  visual  task  loading  on  the  operator  is  high  or  when  visually 
presented  messages  may  be  overlooked  or  misinterpreted.  For  example, 
when  system  response  is  greater  than  15  sec,  an  auditory  signal  can 
indicate  the  "system  ready"  state.  This  allows  the  user  to  use  that 
time  productively  for  other  tasks  without  being  required  to  monitor  the 
visual  display.  Table  40  lists  general  guidelines  which  define  desira¬ 
ble  characteristics  of  noncritical  auditory  signals. 


TABLE  40.  GUIDELINES  FOR  DESIGN  OF  AUDITORY  SIGNALS 
(Source:  Hendricks  et  al.,  1982) 


•  The  auditory  signal  should  be  used  to  alert  and  direct  the  user's 
attention  to  the  appropriate  visual  display. 

•  The  optimum  type  of  signal  ought  to  be  carefully  evaluated,  so  that 
while  not  startling  or  interfering  with  others  in  the  immediate  area, 
it  is  readily  noticed  by  the  user.  Because  of  variable  background 
noises,  the  intensity  should  be  adjustable. 

•  The  intensity,  duration,  and  source  location  of  the  signal  should  be 
selected  to  be  compatible  with  the  acoustical  environment  of  the  in¬ 
tended  receiver  as  well  as  the  requirements  of  other  personnel  in  the 
signal  area. 

e  Auditory  signals  should  be  intermittent  in  nature,  allowing  the  user 
sufficient  time  to  respond.  The  signal  should  be  automatically  shut 
off  by  user  response  action. 

e  Auditory  signals  should  be  sounded  by  system  failures. 

•  Non-critical  auditory  signals  should  be  capable  of  being  turned  off  at 
the  discretion  of  the  user. 


APPLICATIONS 


Attention-getting;  announcing  changes  in  system  state;  declaring  system 
or  I/O  failure. 

CONSTRAINTS 

•  Guidelines  may  not  have  been  empirically  validated. 

KEY  REFERENCES 

1.  Hendricks,  D.,  Kilduff,  P.,  Brooks,  P.,  Marshak,  R.,  &  Doyle,  B. 
(1982).  Human  engineering  guidelines  for  management  information 
systems.  Alexandria,  VA;  U.S.  Army  Materiel  Development  and  Readi 
ness  Command. 

CROSS  REFERENCES 


13.  System  response  time  and  the  effect  on  user  performance  and  satis¬ 
faction 
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